[llvm-commits] [llvm] r124044 - /llvm/trunk/lib/Analysis/InlineCost.cpp

Eric Christopher echristo at apple.com
Sat Jan 22 13:39:06 PST 2011


On Jan 22, 2011, at 1:32 PM, Nick Lewycky wrote:

> On 01/22/2011 01:17 PM, Eric Christopher wrote:
>> Author: echristo
>> Date: Sat Jan 22 15:17:33 2011
>> New Revision: 124044
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=124044&view=rev
>> Log:
>> Only apply the devirtualization bonus once instead of per-call site in the
>> target function.
> 
> Hi Eric, I'm curious about this change. Surely it's better to devirtualize a function with 100 indirect calls in a row than one that has one, right? Could you tell me a bit about what's motivating this?

There's really no guarantee that any of those are all going to be called from a performance perspective, but the real trick is the inlining that is why the virtualization bonus is there. Ideally we'd then want to inline each of those calls we've devirtualized - now we're giving huge inlining bonuses causing enormous code explosion (500+% in a few testcases I've seen) due to inlining enormous functions that may not have any real benefit.

The direction I was going to go next was to separate out the bonuses from the size estimates of the inlining. Then we can apply a bonus minus the size of the function being inlined, etc. This way we'd be able to apply the bonus per inlining site, but it could turn into a minus if it would allow us to theoretically inline a 1000 instruction function at multiple call sites. (In particular imagine inlining a function that passes 2 function pointers in - that each have 10 call sites, but that is 10k instructions long. We'd still inline it.)

Also, I think 500 is a bit too much of a bonus anyhow, but it's going to take some playing around I think.

-eric



More information about the llvm-commits mailing list