On Fri, May 10, 2013 at 11:00:29AM +0200, Richard Biener wrote:
> >> Which
> >> means changing the GOMP runtime in a way to be able to pass a descriptor
> >> which eventually has accelerator code (and a fallback regular function so
> >> you can disable accelerator usage at runtime).
> >
> > It probably should be a list of different codes -- you might have more
> > than one suitable accelerator available.
>
> Of course. And the descriptor should be versioned to avoid future ABI
> changes. Note that I'd always generate code for the CPU as fallback.
If one uses the OpenMP 4.0 accelerator pragmas, then that is the required
behavior, if the code is for whatever reason not possible to run on the
accelerator, it should be executed on host (and the vars can be shared in
that case between the standard host code and the for accelerator targetted,
but actually on host executed, code). Otherwise, the OpenMP runtime as well
as the pragmas have a way to choose which accelerator you want to run
something on, as device id (integer), so the OpenMP runtime library should
maintain the list of supported accelerators (say if you have two Intel MIC
cards, and two AMD GPGPU devices), and probably we'll need a compiler switch
to say for which kinds of accelerators we want to generate code for, plus
the runtime could have dlopened plugins for each of the accelerator kinds.
> > BTW: What about putting this topic on the Cauldron agenda? Is there
> > still time available to discuss what GCC might do regarding accelerators
> > and HW heterogeneity?
Yeah, it would be nice to discuss that. By that time I hope we'll be at
least through parsing of the accelerator stuff, so we can then design what
to do with that info.
Jakub
