[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