This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: [gomp4.1] Handle new form of #pragma omp declare target


Jakub,

On 07/17/2015 08:05 AM, Jakub Jelinek wrote:
Hi!

...

I believe OpenACC has something similar, but no idea if it is already
implemented.

Yes, it is implemented in gomp-4_0-branch.

While the purpose for 'omp declare target' and 'acc declare' are similar, the data movement, via the clauses, provided with the latter make it very different than the former.

The data movement requires that data be moved at the entry and
exit of an 'associated region'. Associated region to mean either
a function, subroutine, entire program or Fortran module. I choose
to implement this in the front-ends.

For discussion purposes, I'll use the C front-end: c_parser_oacc_declare and finish_oacc_declare.

As far as the syntax, OpenMP is alot easier to deal with than
OpenACC. The handling of said is reflected in c_parser_oacc_declare.
Here also is the handling of the numerous data movement clauses.
One in particular requires special handling: create. This can
be seen toward the end of the function, There is a libgomp
component GOACC_register_static (oacc-parallel.c) that is used
in conjunction with the create clause.

The creation and deletion of the 'associated region' is done
in finish_oacc_declare. Depending upon where the directive was
found requires different handling, i.e., global variable scope
versus local variable scope. In addition, if there is data
movement from target -> host, this must be handled appropriately.


...

Ilya, Thomas, thoughts on this?


Jim answering at the behest of Thomas....

If the above explanation is not sufficient please yell. It may
make more sense to carve out the code in question and document
it more thoroughly for discussion purposes. Also the implementation approach in the front-ends may be entirely wrong. There may be an approach to do it in the 'middle'. However, my lack of experience in the middle may have caused me to go down the wrong path.

Jim




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