Re: [RFC][gomp4] Offloading patches (1/3): Add '-fopenmp_target' option

[Ilya Verbin <iverbin at gmail dot com>]

Hi Bernd,

2014/1/27 Bernd Schmidt <bernds@codesourcery.com>:
> Once I worked around this by unsetting the environment variables around this
> compiler invocation here, the next problem is exposed - the code tries to
> link together files compiled for the target (created by the code quoted
> above) and the host (the _omp_descr file, I believe). Linker errors ensue.

Thanks, that's a bug.  Fortunately, it could be fixed easily.

> As mentioned before, I think all this target-specific code has no place in
> lto-wrapper to begin with. For ptx, we're going to require some quite
> different mechanisms, so I think it might be best to invoke a new tool,
> maybe called $target-gen-offload, which knows how to produce an image that
> can be linked into the host executable. Different offload targets can then
> use different strategies to produce such an image.

That's quite a viable way.  We added all this stuff to these patches
to allow other targets to reuse it as much as possible.  I.e. we
wasn't aware if other targets support objcopy et al., so we proposed
our way so that others could reuse it as-is if everything is
available.  It turned out, that the targets differ much in this place,
so as you suggested, it's better to move all this stuff to
target-specific utils.  Certainly, these patches don't pretend to be a
final version - they are just RFC, and we currently only want to show
what we need and find out what other targets need.

> Probably each such image
> should contain its own code to register itself with libgomp, so that we
> don't have to construct a table.

If other targets use another mapping scheme, then I think these tables
could easily be omitted from host/target executables (e.g. we could
add a corresponding flag to the target images descriptor).  But
personally I believe this part is general enough to satisfy all
targets.  Could you please describe how functions would be invoked on
PTX?

> Some other observations:
>  * is OFFLOAD_TARGET_NAMES actually useful, or would any string
>    generated at link time suffice?

Yep, it might be redundant for now, because all we need is target
compilers.  Target names aren't necessary.

>  * Is the user expected to set OFFLOAD_TARGET_COMPILERS, or should
>    this be done by the gcc driver, possibly based on command line
>    options (I'd much prefer that)?

It's supposed to be set by gcc driver.  Initial work in this direction
could be found here:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01242.html

>  * Do we actually need an -fopenmp-target option? The way I imagine it
>    (and which was somewhat present in the Makefile patches I posted
>    last year) is that an offload compiler is specially configured to
>    know that that's how it will be used, and to know what the host
>    architecture is. A $target-gen-offload could then be built with
>    knowledge of the host architecture and installed in the host
>    compiler's libexec install directory.

Our idea here was that a single x86 compiler could serve both as host
and as target compiler, depending on presence of this option.  If
these compilers are always different, then indeed this option isn't
needed.

> Bernd

  -- Ilya