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] Initial support for some OpenMP 4.1 construct parsing


On Fri, Jul 17, 2015 at 07:31:36PM +0300, Ilya Verbin wrote:
> One big question is who will maintain the list of scheduled job, its
> dependencies, etc. - libgomp or each target plugin?
> 
> 
> OpenACC has async queues:
> #pragma acc parallel async(2) wait(1)
> 
> But it's not possible to have 2 waits like:
> #pragma acc parallel async(3) wait(1) wait(2)
> 
> (GOMP_OFFLOAD_openacc_async_wait_async has only one argument with the number of
> queue to wait)
> 
> Thomas, please correct me if I'm wrong.
> 
> In this regard, OpenMP is more complicated, since it allows e.g.:
> #pragma omp target nowait depend(in: a, b) depend(out: c, d)

If it is each plugin, then supposedly it should use (if possible) some
common libgomp routine to maintain the queues, duplicating the dependency
graph handling code in each plugins might be too ugly.

> Currently I'm trying to figure out what liboffloadmic can do.
> 
> 
> BTW, do you plan to remove GOMP_MAP_POINTER mappings from array sections?
> The enter/exit patch for libgomp depends on this change.

My current plan (for Monday and onwards) is to first implement firstprivate
on target construct, once that works hack on the GOMP_MAP_POINTER
replacement, and then rewrite the gimplification rules for target construct
for the new 2.15.5 rules (so that this one does not really break all the
target tests we need the first two working somehow).

	Jakub


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