Hi! On Mon, 30 Sep 2013 09:30:47 +0200, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote: > > Is my understanding correct that the GCC policy regarding extensions such > > as support for OpenACC or OpenMP 4 is: first develop and polish this on a > > branch (such as openacc-1_0-branch or gomp-4_0-branch), and once > > *everything* of the respective standard has been implemented, the > > development branch is then merged into mainline (closing it at the same > > time), instead of committing individual sub-features (such as support for > > only »#pragme acc parallel« but not yet covering the whole respective > > standard) directly to trunk? The issue with the latter, I assume, is > > that such half-finished implementations in trunk might delay/disturb GCC > > releases. > > My actual plan with gomp-4_0-branch is to merge the branch to the trunk > in a week or two.>
Ah, nice! > The missing parts of OpenMP 4.0 support right now are: > 1) Fortran support - didn't have spare cycles for it yet, but I think > initially we can just support C/C++ OpenMP 4.0 and Fortran OpenMP 3.1, > and as time permits add the missing Fortran support > 2) OMP_PLACES/affinity - library only side, plan to work on that this week > 3) target support ICV handling - library side only, plan to work on that this > week > 4) elemental functions - this is currently parsed, but ignored, I'd prefer > this being developed on the gomp-4_0-branch after the branch is merged > with trunk, then committed > 5) offloading - once 3) is supported, we should be hopefully OpenMP 4.0 > compliant with regards to target* constructs, just always do host > fallback, further development of actual offloading should continue > on gomp-4_0-branch 6) Documentation (*.texi) updates. ;-) So, this means gomp-4_0-branch will stay open for development. As we (meaning both Samsung and Mentor Graphics) are interested in building upon 3)/5) does it make sense for us to develop OpenACC support directly on gomp-4_0-branch, does that make sense to you? On Mon, 30 Sep 2013 00:05:55 +0200, I wrote: > OpenACC and OpenMP's target construct are very similar in that they can > be expected to share at least a large part of the "device offloading" > functionality: managing memory mappings and data copying, device > detection, initalization, code offloading, and so on. In my > understanding it makes no sense to duplicate that, and instead the > OpenACC implementation shall re-use what has already been implemented for > OpenMP, or rather: is currently being implemented on gomp-4_0-branch > (using per-device plugins). Does it make sense to you to directly implement the OpenACC runtime library routines acc_* plus internal support routines OACC_* in libgomp, or would you rather have that live in a separate library (built inside [GCC]/libgomp/ or strictly "outside")? Doing it directly as part of libgomp (and having -fopenacc imply -lgomp and all that) will make sharing of existing code easier, but will add a bit of overhead to non-OpenACC users of libgomp (also known as OpenMP users) ;-) -- but I don't think the overhead will really be noticeable, as it'll be just a tiny bit of initial setup (ICV; environment variables parsing, etc.); the (unused) OpenACC-only code won't be paged in by the operating system unless used. > So, how to continue? Would it make sense that we first > rework/stabilitize the general infrastructure in openacc-1_0-branch, or > gomp-4_0-branch, or trunk, or yet another branch -- based on > gomp-4_0-branch? Then, flesh out the implementation of one construct, > OpenACC parallel (for it is simpler than the kernels one)? Then, after > we're happy with that, add the other ones? I'd vote for doing that in gomp-4_0-branch. Grüße, Thomas
pgpktoqW5MSvw.pgp
Description: PGP signature
