Re: Ping Re: [gomp4] Dumping gimple for offload.

["Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>]

Hi Bernd,

I am working on offloading support for OpenMP4, so I'll try to share my vision
of how everything works and answer your questions.

GCC compiles host version of the code (as usual) and dumps Gimple, as it does
for LTO, but for offloading.  Gimple IR is stored only for functions/variables
that have target versions - for OpenMP that means the functions/variables under
'omp declare target' pragma and outlined functions from 'omp target' regions.
Dumped gimple is then picked up by lto-plugin, which performs compilations for
all specified targets (specified either in configure or by compilation flags).
(Note that though we use lto-infrastructure, it possible that we don't do any
link-time optimizations.)

Compiled target images are then embedded into a data-sections of the host binary,
and are registered in a global for all targets descriptor.  This descriptor is
basically an array of pointers to beginning of the images and its sizes.

Along with pointers to images, the descriptor contains pointer to
functions/globals tables and some other data.  Function tables are used to find
the correspondence between host and target versions of functions, that could be
offloaded.

To compile code for target, lto-wrapper calls target compiler, giving it
fat-object with dumped gimple as an input.  This target compiler could actually
be anything that understands Gimple as its input and produces a target image.
(Patch for this part hasn't been submitted yet, but I hope to do it in a near
future).

Another big part of the entire picture is libgomp - a runtime for supporting all
this infrastructure.  To support different targets, we added plugin-support to
libgomp.  Thus, libgomp operates in 'general' terms and calls plugin-hooks, when
it needs to do anything target-specific (examples of such hooks are:
device_run_function, device_init_device, etc.).

So, for each target we need to have two important pieces:
1) compiler, that accepts gimple as its input and produces target image
2) plugin for libgomp, which will implement all device-specific part

That's just a general overview, so I could explain some parts in more details if
you need.  Not everything has already been implemented yet, here is the current
status (also, very general and maybe rough):
 - Plugins support in libgomp.  Done in gomp4-branch.
 - Streaming gimple IR into dedicated sections for later use by target
   compilers.  Done in gomp4-branch.
 - Invoking target compilers and embedding target images into host binary.  Work
   in progress, hope to send the patch soon.
 - Configure options, compile options for specifying offloading targets.  Work
   in progress.

Thanks,
Michael

On 03 Dec 14:00, Bernd Schmidt wrote:
> On 11/29/2013 06:12 PM, Jakub Jelinek wrote:
> > On Fri, Nov 29, 2013 at 06:07:38PM +0100, Bernd Schmidt wrote:
> >> By what mechanism do you choose? This is unclear to me from what I've
> >> seen. Does this involve user action, and what's the advantage of doing
> >> it this way?
> > 
> > See the 3 threads I've mentioned.  The compiler would know the list of
> > available offloading targets (after all, it needs to build libgomp plugins
> > for those targets), and that would be the default, and user could override
> > that through link time command line options (say, ok, while gcc has been
> > configured to support all of hsail-none, ptx-none and x86_64-k10m-linux
> > offloading targets, I only want to support here one of those, and
> > please use these additional options for compilation of that target).
> 
> Ok, IIUC the model is that we just compile all target code for all
> targets (or a subset of them). Is that correct? In that case I can see
> how the code that's on the branch now is sufficient; I'd assumed
> something more fine-grained would be desirable.
> It would be helpful to see the other pieces of this work if they already
> exist.
> 
> 
> Bernd
>