<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 30, 2014 at 3:46 PM, Yin Ma <span dir="ltr"><<a href="mailto:yinma@codeaurora.org" target="_blank">yinma@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6zt" class="a3s" style="overflow:hidden">We found the current SCC<br>
inliner cannot inline a critical function in one of the SPEC2000 benchmarks<br>
unless we increase the threshold to a very large number. Like A calls B<br>
calls C, The SCC inliner will start B -> C and inlined C into B, however,<br>
the performance gain is B to A and B is in a loop of A. However, after<br>
inlining C to B, B becomes very large so B cannot be inlined to A with<br>
default inline threshold.</div></blockquote></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>