[llvm-commits] [llvm] r102798 - in /llvm/trunk: lib/Analysis/InlineCost.cpp test/Transforms/Inline/2009-01-12-RecursiveInline.ll test/Transforms/Inline/noinline-recursive-fn.ll

[Chris Lattner]

On Apr 30, 2010, at 4:13 PM, Dale Johannesen wrote:

>>> I don't much care about this, but why are we doing it?  I don't recall a justification based on performance numbers.  (When I enabled recursive inlining in the first place, I found it mostly affected small benchmarks like fib and factorial, but it can be a big win on those.)
>> 
>> I didn't disable inlining a recursive function "foo" into itself.  I disabled inlining a recursive function "foo" into bar.
> 
> I know, sorry, I wasn't clear.  My question was directed more at Dan.  Although I'm dubious about yours too now that I think about it.   Removing 1 call is still a runtime win, and you lose the big advantage of constant propagation.  Any numbers to back up your argument that this is a good idea?

There are many things that could be a good idea in a contrived case.  For example, if the recursive function usually never recurses, inlining it once can be a great thing to do.  However, in the absence of a cost model to try to make smart decisions, it is good to be conservative.

Dan made the original change because the inliner was inlining self recursive functions that were tail call candidates, bloating code and preventing the optimizer from turning it into a loop, and then running the loop optimizer on it.

-Chris