[PATCHES] A module inliner pass with a greedy call site queue

[Chandler Carruth]

On Wed, Jul 30, 2014 at 3:46 PM, Yin Ma <yinma at codeaurora.org> wrote:

> We found the current SCC
> inliner cannot inline a critical function in one of the SPEC2000 benchmarks
> unless we increase the threshold to a very large number. Like A calls B
> calls C, The SCC inliner will start B -> C and inlined C into B, however,
> the performance gain is B to A and B is in a loop of A. However, after
> inlining C to B, B becomes very large so B cannot be inlined to A with
> default inline threshold.
>

This is a well known and studied limitation of the inliner. I gave a talk
at a prior dev meeting about it. There are specific ways to address it
within the existing inlining framework that I've been working on for some
time, but it requires infrastructure changes to implement.


I'm still very concerned that the code size impact and other impacts have
not been widely analyzed, but only narrowly analyzed. For example, LLVM's
inliner has historically shown over 10% code size advantage across a wide
range of benchmark C++ applications, large and small. I don't think we want
to sacrifice that.


I also don't think you should underestimate the impact of inlining on
virtual dispatch. The collapsing of indirect calls to direct calls is
*very* important and has been carefully tuned in LLVM's current inliner.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140730/972797d0/attachment.html>