<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 1:58 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">----- Original Message -----<br>
> From: "Chandler Carruth" <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "Xinliang David Li" <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>>, "Jiangning Liu" <<a href="mailto:Jiangning.Liu@arm.com">Jiangning.Liu@arm.com</a>>, "LLVM Commits"<br>

> <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>
</div><div class="">> Sent: Wednesday, August 20, 2014 3:49:51 AM<br>
> Subject: Re: [PATCHES] A module inliner pass with a greedy call site queue<br>
><br>
><br>
><br>
><br>
><br>
</div><div class="">> On Wed, Aug 20, 2014 at 1:36 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
> > Also, neither Duncan nor I were able to find copious examples where<br>
> > the lack of such a threshold caused runaway bad inlining decisions<br>
> > *and* this had a gross impact on overall performance. The current<br>
> > worst impact I've found are massive global constructor functions in<br>
> > Chromium which have template-expanded calls to 1000s of small<br>
> > functions inlined into them with no performance benefit and<br>
> > non-trivial code size growth. But so far, this hasn't even been<br>
> > found to be the high order bit in Chromium for either performance<br>
> > or<br>
> > code size, so.... :: shrug ::<br>
><br>
> So the conclusion is that we might not need a limit at all? Sounds<br>
> good to me.<br>
> No, my conclusion is that it isn't worth hacking in a limit to solve<br>
> an immediate, pressing problem. I still think that a limit such as<br>
> the one I describe would be useful,<br>
<br>
</div>You're referring to the fixed-point iteration scheme you outlined? [I'm not sure I'd call that a "limit", but...]</blockquote></div><br>The idea is to incorporate a total size growth of the caller limit. Then you inline up to that point, re-run the optimization passes to let them bring you back under that limit if possible. Rinse, repeat. It allows the inliner to keep inlining as long as the post-inlined code keeps optimizing away, but enforces a total growth cap when the code *doesn't* optimize away.</div>
</div>