<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 12:50 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Nov 20, 2014 at 12:20 PM, Philip Reames<br>
<<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
><br>
> On 11/20/2014 12:07 PM, Mark Heffernan wrote:<br>
><br>
> Rolling back this CL which just improves analysis precision (trip count<br>
> computation specifically) is probably not the right approach.<br>
><br>
> Strongly, strongly agreed with this point.<br>
<br>
</span>Right, I wasn't suggesting that we roll back. I'm not that<br>
revert-trigger happy :)<br>
<br>
I just wanted to report our binary size findings and was curious to<br>
hear more from Mark about his commit.<br>
<br>
I agree that this mostly seems like a bug fix, and if we have problems<br>
with unrolling we should probably look at the thresholds. In an ideal<br>
world our builds should be guided by profiles, but we're not there<br>
yet.</blockquote></div><br>I don't think this is the root of the issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The way in which this would impact the unroller is by uncovering more loops with a *constant* trip count that we can therefore fully unroll. This shouldn't be profile guided and is strict goodness.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The problem is that fully unrolling loops is causing binary size growth. We don't want to stop unrolling loops fully when we can (it radically improves our ability to analyze the function). We should perhaps look at actually using the "loop re-rolling" pass more heavily, scheduling it along with the partial-unroll that happens very late in the pipeline to re-form loops out of very long, repetitive code sequences?</div></div>