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. > 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? Thanks, -- Ilya
