[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

Dale Johannesen dalej at apple.com
Fri Apr 30 16:13:36 PDT 2010


On Apr 30, 2010, at 4:01 PMPDT, Chris Lattner wrote:
>>> 
>>> Dan recently disabled recursive inlining within a function, but we
>>> were still inlining self-recursive functions into other functions.
>> 
>> 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?





More information about the llvm-commits mailing list