Re: [PATCH 5/n] OpenMP 4.0 offloading infrastructure: libgomp

[Ilya Verbin <iverbin at gmail dot com>]

On 07 Oct 16:30, Jakub Jelinek wrote:
> I think it is useful, doesn't have to be in the initial checkin, but I'd
> certainly prefer if from the (optional) --enable-offload-target argument
> it would figure out everything it needs to add for testing.
> And, if mkoffload isn't flexible enough to be convinced to find it in that
> scenario, it better should be made more flexible.

Ok, then we will implement this in a separate patch.

> I thought .gnu.target_lto* sections hold LTO bytecore and are desirable only in the
> ET_REL objects for ld(1)/lto-wrapper purposes.  For large programs containing large
> target regions the LTO bytecode could be very big, so leaving it in the binary is
> undesirable.

Already fixed in kyukhin/gomp4-offload branch.
 
> For .offload_image_section name, wouldn't it be better to prefix that with .gnu?

Renamed to .gnu.offload_images, I'll update the branch tomorrow after testing.

> And, is __gnu_offload_{funcs,vars} named that way just because the plugin isn't able to add
> symbols around the sections for you?  As it doesn't contain a dot, it would collide
> with user declarations put into __attribute__((section ("__gnu_offload_funcs"))).

Renamed to .gnu.offload_{funcs,vars}.
Automatically provided symbols __start__*, __stop__* don't work with shared
libraries, since the symbols from exec override the respective symbols in dso.
 
> Looking at the symbols:
> perhaps it would be better to have . somewhere in the names too, though if you are
> accessing that from C or declaring them in C, it might be too hard to bother.
> It is all in reserved namespace anyway, but use two underscores prefix instead of one
> for those IMHO.

All these symbols are declared/accessed in C, so I renamed them to __offload_*.

On 07 Oct 16:45, Jakub Jelinek wrote:
> Also, something that I believe has been discussed in the past, but can't
> find it on your wiki page nor in *.opt, are option overrides for the
> offloading target, i.e. some option you can pass to the host compiler driver
> during linking that will tell the driver for which offloading targets (if
> any at all) to produce the offloading support (defaulting to all configured
> offloading target is fine) and optionally what extra options beyond what has
> been passed on the command line should be passed to the offloading compiler.
> 
> Say, if I want to link target-1.exe such that it will only support host
> fallback and not x86_64-intelmicemul-linux-gnu , how do I achieve that now?

Unfortunately, this is still under development.  I hope to have a working patch
in a week.  Now, without it, lto-wrapped builds offload images for all offload
targets, specified during configure.

  -- Ilya