LTO and the inlining of functions only called once.
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