Re: Questions about LTO infrastructure and pragma omp target

[Ilya Verbin <iverbin@gmail.com>]

On 23 Aug 13:17, Jakub Jelinek wrote:
> I don't think we should stream into more than one target section.
> There should be just .gnu.target_lto section (or whatever other suitable
> name) and should stream into it:
> 1) all functions and variables with "omp declare target" attribute
> 2) the outlined bodies of #pragma omp target turned into *.ompfn functions
> 3) all the types, symtab etc. needed for that

Why having one target section is preferable than multiple sections for each
function body?

> Then the question is what the plugin should perform with these sections,
> whether it will compile each input .gnu.target_lto section hunk separately
> (as in non-LTO mode), or with -flto also LTO them together.

Yes, it is an important question...  To get started it is easier to implement
"non-target-lto" mode, however this approach should be general enough to extend
it to "target-lto" mode.  Does anyone need it?


On 23 Aug 14:36, Jakub Jelinek wrote:
> On Fri, Aug 23, 2013 at 02:24:42PM +0200, Richard Biener wrote:
> > No, as you will refer to the symbol with the target code from the host
> > code you need a single unified symtab.
> 
> I really think you want two symtabs rather than a unified symtab,
> or just stream a subset of the host symtab into the .gnu.target_lto
> section.  The thing is, the target code (functions, vars, outlined bodies)
> is a strict subset of the host code (because as a fallback, everything
> needs to be able to run on the host), but when not compiling originally with
> -flto, we IMHO should stream just the target subset, not everything
> (and for -flto stream both the target subset into one section and everything
> (host code) as we do right now, either with fat or slim lto objects).

I also think that having two symtabs looks better.  There is no direct refs to
the target symbols from the host code.  And (as far as I see it) unified symtab
will lead to mess in places, where host and target symbols should be handled
differently.

Thanks,
    -- Ilya