Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi Thomas! I fixed these patches: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01520.html . Instead of adding new OACC_* data structures and macros for OpenACC clauses these patches reuse existing OMP_* functionality and extends it. But OpenACC-specific constructs and directives still named as OACC_*. Thomas, as I noticed you privately, I can't use OpenMP 4.0 map clause to represent OpenACC data clauses in front-end, so old form of them still there. Successfully bootstrapped with no new regressions on x86_64-unknown-linux-gnu. OK for gomp-4_0-branch? -- Ilmir.
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi, Thomas! Likewise, if you have any comments on my patch series for »initial support for OpenACC data clauses«, I'd like to hear them. Sure: + else if (!strcmp (present_or_copy, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPY; + else if (!strcmp (present_or_copyin, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPYIN; + else if (!strcmp (present_or_copyout, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPYOUT; + else if (!strcmp (present_or_create, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_CREATE; For these combined clauses the specification specifies short names: pcopy, pcopyin, pcopyout and pcreate (see 2.6.5.9 - 2.6.5.12 of OpenACC 2.0). And otherwise, as you state that you'd base your work on this, it probably makes sense if I commit my patches soon? (I now also have to rebase my patches onto the updated gomp-4_0-branch.) Yes, it would be great! -- Ilmir.
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi, Thomas! Thank you for your review. I agree with all your notes. I'm going to reuse your implementation of data clauses, add minimal GIMPLE infrastructure, and then resend patches. -- Ilmir.
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi! On Mon, 27 Jan 2014 17:12:04 +0400, Ilmir Usmanov i.usma...@samsung.com wrote: Thank you for your review. You're welcome. Hopefully the merge from trunk into gomp-4_0-branch that I just committed doesn't cause you additional work -- but as I told in my other email, there were no conflicts visible, so I hope that'll be an easy update. Otherwise, I'm happy to assist. I agree with all your notes. I'm going to reuse your implementation of data clauses, add minimal GIMPLE infrastructure, and then resend patches. Likewise, if you have any comments on my patch series for »initial support for OpenACC data clauses«, I'd like to hear them. And otherwise, as you state that you'd base your work on this, it probably makes sense if I commit my patches soon? (I now also have to rebase my patches onto the updated gomp-4_0-branch.) Grüße, Thomas pgpPzeUtDwQM9.pgp Description: PGP signature
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi! On Thu, 23 Jan 2014 22:01:19 +0400, Ilmir Usmanov i.usma...@samsung.com wrote: Jakub, could you review these patches, if they are OK to gomp-4_0-branch? Thomas, please, have a look whether this implementation applies current OpenACC support style. So, in context of http://news.gmane.org/find-root.php?message_id=%3C87a9elqolz.fsf%40schwinge.name%3E, I'll give a try with reviewing the patches you sent. But, don't hold your breath -- it's late on a Friday evening already (and even later in your timezone). ;-) These patches port OpenACC 1.0 support in fortran front-end from openacc-1_0-branch to gomp-4_0-branch. In addition, they extend middle-end infrastructure with necessary GENERIC nodes. Again, many thanks for porting these patches! That will definitely help in synchronizing and then parallelizing our development work. Patches support almost all directives (except loop) and all clauses from the specification ver. 1.0 (without subarrays). [...] That is totally fine; incremental development. Grüße, Thomas pgpQqr304i2Zf.pgp Description: PGP signature
[PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi all. Jakub, could you review these patches, if they are OK to gomp-4_0-branch? Thomas, please, have a look whether this implementation applies current OpenACC support style. These patches port OpenACC 1.0 support in fortran front-end from openacc-1_0-branch to gomp-4_0-branch. In addition, they extend middle-end infrastructure with necessary GENERIC nodes. Patches support almost all directives (except loop) and all clauses from the specification ver. 1.0 (without subarrays). In addition to OpenACC version 1.0, patches add functionality from OpenACC 2.0: enter data and exit data directives. Patches stub gimplification of OpenACC constructs and directives, except OACC_PARALLEL node, to prevent crashes. I didn't port loop directive, since in openacc-1_0-branch we consider it as OpenACC construct, like kernels or parallel. Hence, OpenACC loop and OpenMP for directives differ. It means there are no checks in C FE (in openacc-1_0-branch) and the functionality will be modified, in both FEs and back-end. As far as loop directive doesn't exist in GENERIC, fortran FE doesn't transform it from internal EXEC_OACC_LOOP statement. Consequenly, there are no tests to check the directive. Lately, I'm going to port loop directive, too. Inspite of the fact that subarrays do exist in openacc-1_0-branch, they don't present in patches. Currently, we are using our own GENERIC nodes to represent subarrays. I'm going to replace them with existing functionality, like ARRAY_RANGE_REF. Full list of supported fuctionality is the following: Constructs/directives: Namefront-end GENERIC tests parallelY Y Y kernels Y Y Y dataY Y Y host_data Y Y Y loopY N N update Y Y Y waitY Y N cache Y Y N declare Y Y Y kernels loopY N N parallel loop Y N N enter data (2.0)Y Y Y exit data (2.0) Y Y Y Clauses Namefront-end GENERIC tests async Y Y Y waitY Y Y num_gangs Y Y Y num_workers Y Y Y vector_length Y Y Y if Y Y Y reduction Y Y Y copyY Y Y copyin Y Y Y copyout Y Y Y create Y Y Y delete (2.0)Y Y Y present Y Y Y present_or_copy Y Y Y present_or_copyin Y Y Y present_or_copyout Y Y Y present_or_create Y Y Y deviceptr Y Y Y private Y Y Y firstprivateY Y Y default(none) (2.0) Y N Y collapseY Y N gangY Y N worker Y Y N vector Y Y N seq Y Y N auto (2.0) Y N N tileY N N independent Y Y N device_resident Y Y N Successfully bootstraps on x86_64 with no regressions. OK to commit? -- Ilmir
