[llvm-commits] [llvm] r98099 - in /llvm/trunk: include/llvm/Analysis/InlineCost.h include/llvm/Transforms/IPO/InlinerPass.h lib/Analysis/InlineCost.cpp lib/Transforms/IPO/InlineAlways.cpp lib/Transforms/IPO/InlineSimple.cpp lib/Transforms/IPO/Inl

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Mar 9 16:05:13 PST 2010


On Mar 9, 2010, at 3:52 PM, Daniel Dunbar wrote:

> Hi Jakob,
> 
> On Tue, Mar 9, 2010 at 3:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> Author: stoklund
>> Date: Tue Mar  9 17:02:17 2010
>> New Revision: 98099
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=98099&view=rev
>> Log:
>> Try to keep the cached inliner costs around for a bit longer for big functions.
>> 
>> The Caller cost info would be reset everytime a callee was inlined. If the
>> caller has lots of calls and there is some mutual recursion going on, the
>> caller cost info could be calculated many times.
>> 
>> This patch reduces inliner runtime from 240s to 0.5s for a function with 20000
>> small function calls.
>> 
>> This is a more conservative version of r98089 that doesn't break the clang
>> test CodeGenCXX/temp-order.cpp. That test relies on rather extreme inlining
>> for constant folding.
> 
> That test doesn't *have* to pass, and we can change it if need be.
> However, it sounds like this should just be a performance improvement
> not a functionality change, so I wouldn't expect it to break the test.

Yes, it caught me by surprise too.

That test relies on inlining and constant folding to reduce function calls to just a constant. My "performance improvement" didn't expect a function to be significantly smaller after inlining, and so it cached a very outdated cost.

It is possible that my patch will change the generated code in other cases that rely on massive constant folding. I hope that it will only do that in degenerate cases. The more conservative version only cheats for functions with more than 10 basic blocks and 1000 instructions. I would not normally expect such a big function to collapse into something that can be considered for inlining.

/jakob





More information about the llvm-commits mailing list