<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 10:00 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="">> I've tried to check for compile-time regressions here by running llc<br>

> over a merged (but not LTO-ed) clang bitcode file and observed at most<br>
> a 3% slowdown in llc. Given that this is essentially a worst case (none<br>
> of opt or clang are running at this phase) I think this is tolerable.<br>
> The actual LTO case should be even less costly, and the cost in normal<br>
> compilation should be negligible.<br>
<br>
</div></div>We’re seeing a larger impact, with widespread regressions in the range of 2-4% on overall clang compile times (non-LTO), including the optimization time. Is there any way you can think of to speed this up?</blockquote>
</div><br>How confident are you that it is this patch? I'm not questioning the regression -- we've been seeing some as well, just curious whether its *definitely* this patch or just something recent and this patch called out the possibility...</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As for speeding it up, I have ideas, but it is very hard. the SDAG data structures make everything really, really slow.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
If it is definitely this patch, it would be helpful to have representative test cases in IR form. When benchmarking the compile time myself, my test cases showed overall compile time regressions in the 1% and smaller range (below the noise floor of my measurements honestly).</div>
</div>