LTO and the inlining of functions only called once.

[Jeff Law]

On 10/12/09 19:18, Michael Matz wrote:
> Hi,
>
> On Mon, 12 Oct 2009, Jeff Law wrote:
>
>    
>> To put things in perspective, the particular person I spoke with spent
>> many days trying to understand why a particular function wasn't being
>> inlined -- presumably they'd see "grep<ugly function>  logfile" as a
>> huge improvement over the days and days of twiddling sources, tuning
>> options, etc, even if that presented them with a large amount of data to
>> analyze.
>>      
> If we would listen to such requests by providing the requested
> information, nothing stops users from asking to have something like that
> also for other transformations.  Like "I've spent days and days with
> analyzing why this loop isn't unrolled, I'd like to have -Winfo-unroll to
> tell me exactly when a loop is unrolled, and when it isn't for which
> reason".  Make "loop is unrolled" be $TRANSFORMATION and it becomes silly.
> I don't think this is reductio ad absurdum.  We have dump files for
> exactly such information.  Maybe the latter could be molded (via an new
> flag) into something less detailed than now, but still containing the
> larger decisions.
>    
I'm virtually certain this customer would ask for that precise 
information about unrolling once they can get it for inline functions :-)

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.

jeff