Re: [gomp4, openacc-1_0-branch] Re: OpenACC branch

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 30 Sep 2013 09:30:47 +0200, Jakub Jelinek <jakub@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

Attachment: pgpP9QBHrHzx7.pgp
Description: PGP signature