Hi! 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? Grüße, Thomas
pgpYa4_ZiFyzF.pgp
Description: PGP signature
