Re: [PATCH] ipa-inline.c cleanups

[Jan Hubicka <jh at suse dot cz>]

> Attached are three patches that clean up small issues in ipa-inline.c.
> 
> 1) adjustment for nesting in cgraph_edge_badness is backward if  
> badness is < 0.
> In the function cgraph_edge_badness, we calculate a signed value to  
> represent desirability to inline, where smaller is better.  To  
> encourage inlining of calls that appear within a loop, we have the  
> following code:
> 
>     badness >>= nest;
> 
> If badness is negative, however, this adjustment discourages inlining  
> of a call within a loop by increasing badness.  Note that since  
> "nest" values are not currently calculated, this fix has no effect at  
> the moment  (I mentioned this before, and Honza indicated he intended  
> to address it at some point: http://gcc.gnu.org/ml/gcc-patches/ 
> 2005-06/msg00779.html).  Attached as "nestshift.patch", and tested  

I am still planning to benchmark this with SPEC IMA support, but it is
badly broken for months...  Yesterday I run some tests with IPA inlining
and once the ipa-reference bug is fixed, I think it will be possible to
do the test...

I think the change should be more or less noop as we inline all the
functions having negative baddness (since they are smaller than call
site), but I guess your patch makes things cleaner.

> with i686-pc-linux-gnu with no regressions.  OK for mainline?
> 
> 2) fix for failed inlining diagnostics
> In some instances, the diagnostic messages that are emitted into the  
> dump files for inlining are incorrect.  For example, if a function is  
> not inlined because it exceeds the "max-inline-insns-auto" size, it  
> is reported as failing for exceeding the "max-inline-insns-single"  
> size instead.  This can be confusing when working with the dump  
> files.  Attached as "limit-notify.patch", and tested with i686-pc- 
> linux-gnu with no regressions.  OK for mainline?
> 
> 3) comment fixes in cgraph_edge_badness
> These comments refer to wanting to use "loop depth" and "frequency  
> information", but I think both of those are already used in the  
> function.
> Also, the comments claim that returning MAX_INT prevents a function  
> from being inlined, but I can't see any evidence of that being true.   

I used to return MAX_INT for cold calls but later moved the test outside
badness function without noticing this.  Thanks!

The patches are OK for mainline modulo Steven's 0/NULL comment.
Thanks,
Honza
> Attached as "badness-comments.patch", and tested by rebuilding with  
> patch installed.  OK for mainline?
> 
> - Josh
>