<div dir="ltr">I ran SPEC and the performance difference was in the noise.  My motivation for tackling this was that on some internal code we had some "#pragma unroll" marked loops which could not be unrolled because they had more than one exit.  If this patch is causing significant bloat with no benefit (can you measure any performance differences?), the place to solve this in the unrolling heuristics.  Rolling back this CL which just improves analysis precision (trip count computation specifically) is probably not the right approach.  Have you tried tweaking the unrolling thresholds to see how it affects Chrome's code size and performance?  <div><div><br></div><div>Mark</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 11:13 AM, 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">Sorry for reviving an old thread.<br>
<span class=""><br>
On Fri, Oct 10, 2014 at 10:39 AM, Mark Heffernan <<a href="mailto:meheff@google.com">meheff@google.com</a>> wrote:<br>
> Author: meheff<br>
> Date: Fri Oct 10 12:39:11 2014<br>
> New Revision: 219517<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=219517&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=219517&view=rev</a><br>
> Log:<br>
> This patch de-pessimizes the calculation of loop trip counts in<br>
> ScalarEvolution in the presence of multiple exits. Previously all<br>
> loops exits had to have identical counts for a loop trip count to be<br>
> considered computable. This pessimization was implemented by calling<br>
> getBackedgeTakenCount(L) rather than getExitCount(L, ExitingBlock)<br>
> inside of ScalarEvolution::getSmallConstantTripCount() (see the FIXME<br>
> in the comments of that function). The pessimization was added to fix<br>
> a corner case involving undefined behavior (pr/16130). This patch more<br>
> precisely handles the undefined behavior case allowing the pessimization<br>
> to be removed.<br>
<br>
</span>This caused a 50 k regression in Chromium's binary size due to more<br>
unrolling. I suspect it's something we'll have to take, but was<br>
wondering if you have any numbers showing performance benefit here?<br>
<br>
Thanks,<br>
Hans<br>
</blockquote></div><br></div>