LTO and the inlining of functions only called once.

Jeff Law
Tue Oct 13 15:15:00 GMT 2009

On 10/13/09 03:41, Paul Brook wrote:
>> Nothing you've said changes  the fact that there are a class of users
>> for whom that information is vital and we ought to spend some time
>> thinking about how to provide the information in a form they can
>> digest.  GCC dumps as they exist today are largely useless for a non-GCC
>> developer to use to understand why a particular transformation did or
>> did not occur in their code.  This has come up time and time again and
>> will continue to do so unless we find a way to provide visibility into
>> the optimizer's decision making.
> My guess is anyone inspecting the code and optimizer decisions at this level
> is also going to want to strongarm the result they want when the compiler
> makes the "wrong" decision. i.e. detailed unroller diagnostics are only of
> limited use without (say) #pragma unroll.
Perhaps.  Of course in this customer's case they're looking at 20%+ 
hits, so a "wrong" decision is quite costly.  At least with the inliner 
they have a fair number of knobs they can turn once they know which 
heuristic is preventing inlining the key function(s) -- for other passes 
we don't have nearly as many knobs.


More information about the Gcc mailing list