[LLVMdev] LLVM Inliner
Xinliang David Li
xinliangli at gmail.com
Tue Nov 30 14:41:36 PST 2010
On Tue, Nov 30, 2010 at 2:29 PM, Chris Lattner <clattner at apple.com> wrote:
> On Nov 30, 2010, at 2:19 PM, Xinliang David Li wrote:
> I understand that, but that implies that you have some model for code
>> locality. Setting a global code growth limit is (in my opinion) a hack
>> unless you are aiming for the whole program to fit in the icache (which I
>> don't think anyone tries to do :).
> Yes, global growth limit may be good for size control, but is a hack for
> control icache footprint. However, as I mentioned, the bottom up inline
> scheme make it impossible to use any heuristics involving 'global limit'
> which can be more complicated and fancier than the simple growth limit. For
> instance, there is no restriction that only one global limit can be used ---
> the compiler can partition the call graph into multiple locality regions,
> and set icache limit for each region. The inlining order can be done on a
> region by region basis. For each region, the region limit is applied and the
> priority queue must be used.
> Yes, I understand that. But why is a global limit useful? What problem
> does it solve? If it is to cap "runaway inlining" there are better ways to
> do it. You agree that it isn't for icache optimization, so what value does
> it serve?
We have an internal application that aggressive inlining in IPO (LIPO) leads
to up to 30% performance penalty due to icache misses. Mark fixed the
problem by using icache footprint analysis.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev