This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO inlining of transactional builtins
On Tue, Jun 26, 2012 at 10:29 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Mon, Jun 25, 2012 at 4:32 PM, Richard Henderson <rth@redhat.com> wrote:
>> > On 2012-06-22 06:08, Richard Guenther wrote:
>> >> Do I understand correctly that inlining the builtin at expansion time is not
>> >> good because the implementation detail may depend on how libitm was
>> >> configured?
>> >
>> > More or less, yes.
>> >
>> > We want tm in gcc to be useful to researchers experimenting in the area.
>> > That means not building stuff into the main compiler beyond the ABI.
>> > The ABI is just a function call.
>> >
>> > However, in some implementations (including our own) the ABI call is a
>> > small wrapper that calls a function in a dispatch table. ?Avoiding the
>> > call-to-call at least in static linking situations is more or less
>> > exactly what LTO does best.
>> >
>> > Unfortunately, we have a real phase ordering problem here. ?LTO is also
>> > what gives us the visibility into the program itself and allows us to
>> > clone functions for tm based on what's in the transaction.
>>
>> 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.
>
> I would say that double streaming would be more expensive than making WPA stage to load in the relevant function bodies and modify them if the tm pass really can not be split into proper IPA pass (at the moment I do not see why).
I'm not sure TM people care about double streaming cost ;) As far as I can
see TM people want the non-lowered form go through at least loop optimizations,
so I don't see how even a proper IPA pass would help here. As of cherry-picking
function bodies at late state, yes, that would be another missing feature to
consider. But it would at least need the full WPA callgraph to be available,
or in case of static libraries the linker plugin would need to feed even unused
archive parts to WPA ... thus it would require some fake symtab entries we'd
need to feed to the linker plugin. Quite some special case code in this case.
Richard.
> Honza
>>
>> Richard.
>>
>> >
>>
>> > r~