<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 1:36 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><div class="">> 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 or<br>
> code size, so.... :: shrug ::<br>
<br>
</div></div>So the conclusion is that we might not need a limit at all? Sounds good to me.</blockquote></div><br>No, my conclusion is that it isn't worth hacking in a limit to solve an immediate, pressing problem. I still think that a limit such as the one I describe would be useful, and might allow us to be more aggressive in certain circumstances than we are without adverse effects. It would also improve code size in specific cases that seem useful, just not pressing.</div>
</div>