Questions about LTO infrastructure and pragma omp target

Richard Biener richard.guenther@gmail.com
Tue Sep 17 11:56:00 GMT 2013


On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin <iverbin@gmail.com> wrote:
> On 17 Sep 10:12, Richard Biener wrote:
>> It looks more like a hack ;)  It certainly doesn't look scalable to multiple
>> target ISAs.  You also unconditionally invoke the target compiler (well, you
>> invoke the same compiler ...)
>
> Yes, I currently call the "target" compiler unconditionally, but it can be
> placed under a flag/env var/etc.  When we have multiple target ISAs, multiple
> target compilers will be invoked.  Each of them will read same IL from
> .gnu.target_lto_ and produce an executable for its target.
> Why this approach is not scalable?

Are you sure we have the same IL for all targets and the same targets
for all functions?  That would certainly simplify things, but you still need
a way to tell the target compiler which symbol to emit the function on
as the compile-stage will already necessarily refer to all target
variant symbols.

>> As far as I understand your patch the target IL is already produced by
>> the compile stage (always? what about possible target IL emit from
>> -ftree-parallelize-loops?)?
>
> Yes, I assume that IL is already produced, somehow like this:
> http://gcc.gnu.org/ml/gcc/2013-09/msg00123.html
> Probably the compile stage should somehow inform the lto-wrapper, that target
> compilers should be called.

I mean that (speaking in LTO way), you can end up emitting "target IL" from
the LTRANS stage.  So you'd re-run the LTO linker plugin and lto-wrapper
at the final link stage in case you compile with -flto(?)

>> As I understand Jakub he prefers things to work without -flto as well, so
>> target IL has to be handled by a different linker plugin and LTO would merely
>> be required to pass the target IL sections through the LTO pipeline and re-emit
>> it during LTRANS?
>
> If we want to reuse "LTO pipeline", the LTO infrastructure should be turn on
> (i.e. lto-wrapper should be called).
> With -flto, lto-wrapper will perform all usual things (WPA+LTRANS) + invoke all
> necessary target compilers.
> Without -flto it will merely invoke target compilers.
> I do not see how different linker plugin can help.  It will run lto-wrapper same
> way like current plugin?

Well, it certainly would be less LTO specific.

Richard.

> Thanks,
>   -- Ilya



More information about the Gcc mailing list