| Message ID | cover.1576648001.git.julian@codesourcery.com |
|---|---|
| Headers | show |
| Series | OpenACC 2.6 manual deep copy support | expand |
Hi! On 2019-12-17T22:02:25-0800, Julian Brown <julian@codesourcery.com> wrote: > This patch series provides support for OpenACC 2.6's manual deep copy > (attach/detach) feature. Thanks. There is high pressure to get this functionality into GCC 10, but remaining time is short, given upcoming winter holidays, and GCC development stage 3 end. The big "OpenACC reference count overhaul" is a prerequisite for the actual "OpenACC 2.6 manual deep copy support". Integrating into GCC trunk in incremental pieces these changes has taken a considerable amount of time, due to having to research a lot of the existing GCC implementation as well as intended semantics. While we made good progress, it's not complete yet. I very much would like to continue working this in an incremental fashion, however, due to shortage of time, this is not possible. Under protest I thus now rubber-stamp approve all the patches posted here (to the extent I'm able to), without further review now, and I'm planning to next year then do post-commit review, and revisions as required. > Many of these patches have been submitted > previously, but this series has been rebased and the large deep-copy > part proper has been split into several pieces for ease of review. Again: at least as far as I'm concerned, "ease of review" doesn't mean to artificially split a patch into several pieces per component or directories/files touched (I don't need separate patches for 'libgomp.oacc-c-c++-common/', and then 'libgomp.oacc-fortran/'), but instead per self-contained functional change, incrementally. Grüße Thomas
On Wed, 18 Dec 2019 18:44:04 +0100 Thomas Schwinge <thomas@codesourcery.com> wrote: > Hi! > > On 2019-12-17T22:02:25-0800, Julian Brown <julian@codesourcery.com> > wrote: > > This patch series provides support for OpenACC 2.6's manual deep > > copy (attach/detach) feature. > > Thanks. > > > There is high pressure to get this functionality into GCC 10, but > remaining time is short, given upcoming winter holidays, and GCC > development stage 3 end. The big "OpenACC reference count overhaul" > is a prerequisite for the actual "OpenACC 2.6 manual deep copy > support". Integrating into GCC trunk in incremental pieces these > changes has taken a considerable amount of time, due to having to > research a lot of the existing GCC implementation as well as intended > semantics. While we made good progress, it's not complete yet. I > very much would like to continue working this in an incremental > fashion, however, due to shortage of time, this is not possible. > Under protest I thus now rubber-stamp approve all the patches posted > here (to the extent I'm able to), without further review now, and I'm > planning to next year then do post-commit review, and revisions as > required. Thanks. I'm committing the following patches: Use aux struct in libgomp for infrequently-used/API-specific data OpenACC reference count overhaul Use gomp_map_val for OpenACC host-to-device address translation Factor out duplicate code in gimplify_scan_omp_clauses OpenACC 2.6 deep copy: attach/detach API routines OpenACC 2.6 deep copy: libgomp parts OpenACC 2.6 deep copy: middle-end parts OpenACC 2.6 deep copy: C and C++ front-end parts OpenACC 2.6 deep copy: Fortran front-end parts OpenACC 2.6 deep copy: C and C++ execution tests OpenACC 2.6 deep copy: Fortran execution tests Fortran polymorphic class-type support for OpenACC I've omitted the "OpenACC reference count consistency checking" patch for now. A couple of patches needed readjusting for code that landed on trunk since my last rebase/repost (in particular "Use gomp_map_val..." and "OpenACC reference count overhaul"), so I've attempted to fix those in the lowest-impact way possible to avoid regressions. Apologies for any oversights! Additionally I've made some improvements suggested by Tobias in the Fortran front-end patch (thanks!). (An earlier iteration of the deep copy patches were submitted previously at the end of 2018, and were approved by Jakub -- pending approval by Thomas. See https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01292.html. I hope Thomas's rubber stamp, plus that email, are sufficient to allow this code into mainline.) > > Many of these patches have been submitted > > previously, but this series has been rebased and the large deep-copy > > part proper has been split into several pieces for ease of review. > > Again: at least as far as I'm concerned, "ease of review" doesn't > mean to artificially split a patch into several pieces per component > or directories/files touched (I don't need separate patches for > 'libgomp.oacc-c-c++-common/', and then 'libgomp.oacc-fortran/'), but > instead per self-contained functional change, incrementally. Understood, but some split-out parts fall under other individual reviewers' areas of responsibility (e.g. the Fortran front-end stuff). Plus the big patch was getting kind of unwieldy. Cheers (and happy Christmas everyone!), Julian