In theory we should be able to do multiple "LTO" passes. So we could do
a.c a.o
... -> -> WPA -> LTRANS and TM lowering -> WPA -> LTRANS and RTL
expand
x.c x.o
Thus, after a first wave of WPA and LTRANS in non-lowered TM we can,
after the TM lowering in the first LTRANS phase write out LTO bytecode again
and re-start WPA from that. It might get tricky with respect to how we drive
the compile via the linker plugin but in theory GCC itself should not care
if the LTO objects that we feed into WPA stage come from early optimizations
or from LTRANS optimizations (well, you have to cut off at a suitable place
before RTL expansion of course).
So - I suppose enhancing the infrastructure for such multiple runs through
WPA / LTRANS would be a nice thing to have anyways and would probably
solve your issue, too.
Richard.
I'm not particularly thrilled by the overhead, but I do agree that this
approach has the potential for being more generic and thorough.
Also, with the double streaming, we could move ipa_tm to a full IPA
pass, and solve this...
foo.c: bar.c
foo () { bar() { ... }
__transaction {
bar();
}
}
...for which we currently do not clone bar on TM.
So unless I hear otherwise (AFAIK rth is also on board with this), I'd
prefer to go this route, but will not be able to start work on it until
I return from vacation 2 weeks after Cauldron.
I'd be delighted to receive tips, feedback, and advice along the way.
I'll be giving away beers at Cauldron for anyone who wants to help,
though at this point, I think I owe Richi a few kegs. :)
Aldy
