This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Initial submission of OpenACC support integrated into OpenMP's lowering and expansion passes


Here is our take of adding OpenACC support to GCC's front end and middle
end.  What I post here (that is, as replies to this email, to gcc-patches
only) is still very incomplete, but hopefully enough to outline the
general approach, and I'd like to commit these patches to gomp-4_0-branch
-- OK?  Also, may I additionally commit those patches to trunk that don't
have anything specific to OpenACC in them (such as the first two
preparation patches), which I assume will save some work when merging
between trunk and gomp-4_0-branch later on?

Due to the conceptual similarity compared to OpenMP, and that (later) it
is reasonable to expect to embed OpenACC directives into OpenMP ones, the
approach I've chosen is to directly embed OpenACC handling into the
existing OpenMP infrastructure/passes.  I had first begun implementing
separate OpenACC lowering and expansion passes, but then found myself
re-implementing/copying more and more of the existing OpenMP passes'
code, realized that makes no sense, and we shall instead handle these
directly together in one set of passes -- which also happens to
facilitate the interoperation requirement.

For the same reasons, OpenACC's runtime library shall be implemented in
libgomp next to OpenMP's.  Jakub's already approved this approach
generally.  This patch series doesn't contain any substantial rumtime
library work yet; the last patch adds GOACC_parallel, which so far simply
branches to GOMP_target.  There's more to come.

This is in contrast to Samsung's work, who are implementing OpenACC
separately from the existing OpenMP support.  Yet, I hope we'll be able
to share/re-use at least front end and some middle end code.

Our work builds on what has (briefly) been discussed before, for example
at the GNU Tools Cauldron's Accelerator BOF in this summer.  For the
moment, while still getting the concepts clear, I'm adding new
GENERIC/GIMPLE codes and their handling for OpenACC constructs (for the
implementation of OpenACC parallel "borrowing" from OpenMP target) -- the
long-term goal still is to evolve all these into general "acceleration"
abstractions, evolve the GCC OpenMP infrastructure and passes into
general "acceleration" passes.  As discussed, it makes sense to do this
generalization work later on, once we have a better understanding of what
we actually need.

We directly strive for OpenACC 2.0 support, skipping OpenACC 1.  We're
focussing on the C front end implementation first, following on with C++
and Fortran later on.

The patches I send here only contain a bare minimum of documentation
changes.  I already have further documentation changes prepared (source
code comments as well as Texinfo manual updates); will polish and send
these only once the approach we've chosen has generally been approved.

Comments on the approach and/or patches?


Attachment: pgpu5iGdwe_5A.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]