On Tue, Sep 17, 2013 at 03:30:10PM +0400, Ilya Verbin 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?
>
> > 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.
-ftree-parallelize-loops right now only parallelizes loops, doesn't in any
way attempt to offload them, and I don't plan to work on anything like that
in the near future (it would need probably a different option and lots of
work), what is being offloaded right now is only code explicitly marked by
users. For -flto -ftree-offload-loops or whatever the option would be,
you'd need to do LTO stuff in the plugin first and pick .gnu.target_lto_*
sections from whatever came out of LTO.
> > 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?
I don't see why you'd need a different plugin, the section names are
unambiguous, so all you can do is just handle differently .gnu.lto_* and
.gnu.target_lto_* sections in the plugin. The former are handled without
changes from current behavior, the latter are just compiled by target
compiler, shared libraries temporarily extracted from special sections of
host shared libraries and linked with target linker, then just embedded into
a data section of the host binary resp. shared library.
Jakub
