[PATCH] Drop callee function size limits for IPA inlining

[Michael Matz]

Hi,

On Fri, 18 Feb 2011, Jan Hubicka wrote:

> We have c-ray with relatively large raysphere (polyhedron's fatigue is 
> the same case as analyzed in one of the PRs).  We declare decision on 
> whether to inline it to be global property. We set growth to 30% that is 
> safely big enough to make raysphere inlined on c-ray.
> 
> However now if you make c-ray not a stupid benchmark, but part of big 
> program, then raysphere won't be inlined with LTO since the other useful 
> calls from big program leading to smaller callees will win.

Um, yes of course.  But what you're basically saying is: "with 
the current heuristics a different program than what the experiment is 
about will not work as designed".  Well, that's to be expected.

_Of course_ the definition of badness and usefullness must be changed too 
for the removal of pruning to not have undesired effects.  I'm really not 
sure what you're getting at, you're pointing at a clearly unfinished 
experiment and argue that this approach can't work for reasons in the 
current implementation of heuristics.  /me confused

> Badness is more or less function of the callee size with few extra local 
> hints based on caller side so it is quite safe to assume that the 
> fibheap queue is ordered by size of the function and we cut of much 
> earlier than the current default of 40 instructions in size.

Yes, that is the case currently.  But you're argueing as if this has to be 
the case forever.  The whole point is to also introduce different 
definitions of badness and usefullness.  For instance taking into account 
the actual parameters and their influence on the (then inlined) body.


Ciao,
Michael.