[LLVMdev] LLVM Inliner

[Xinliang David Li]

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.

Thanks,

David



>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101130/504e6619/attachment.html>