
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 11, 2012, at 4:01 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Wed, Apr 11, 2012 at 9:46 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>

On Apr 11, 2012, at 11:33 AM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>

<br>

> If your patch consistently leads to lower computed inlining costs,<br>

> perhaps we should lower the inlining threshold?<br>

<br>

</div>The inlining thresholds haven't been calibrated for many years. It is time to recalibrate.<br>

<br>

Somebody should plot the code size vs speed curve and pick thresholds for -Oz, -Os, -O2, and -O3.<br></blockquote><div><br></div><div>I actually plan to do this, but haven't had time, and would like to finish changes to the inliner, or to things that dramatically effect the speed we see so that the numbers are more stable / meaningful.</div></div></blockquote><div><br></div><div>Makes sense.</div><br><blockquote type="cite"><div class="gmail_quote"><div> If others have a faster way of generating this data than I do (mine would take many days on a benchmarking rig), by all means.</div>

</div>

</blockquote></div><br><div>I would run SPEC with many threshold settings, recording aggregate code size and SPEC score. Many days sounds reasonable.</div><div><br></div><div>Thanks for doing this.</div><div><br></div><div>/jakob</div><div><br></div></body></html>