[llvm] r219517 - This patch de-pessimizes the calculation of loop trip counts in

[Mark Heffernan]

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?

Mark

On Thu, Nov 20, 2014 at 11:13 AM, Hans Wennborg <hans at chromium.org> wrote:

> Sorry for reviving an old thread.
>
> On Fri, Oct 10, 2014 at 10:39 AM, Mark Heffernan <meheff at google.com>
> wrote:
> > Author: meheff
> > Date: Fri Oct 10 12:39:11 2014
> > New Revision: 219517
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=219517&view=rev
> > Log:
> > This patch de-pessimizes the calculation of loop trip counts in
> > ScalarEvolution in the presence of multiple exits. Previously all
> > loops exits had to have identical counts for a loop trip count to be
> > considered computable. This pessimization was implemented by calling
> > getBackedgeTakenCount(L) rather than getExitCount(L, ExitingBlock)
> > inside of ScalarEvolution::getSmallConstantTripCount() (see the FIXME
> > in the comments of that function). The pessimization was added to fix
> > a corner case involving undefined behavior (pr/16130). This patch more
> > precisely handles the undefined behavior case allowing the pessimization
> > to be removed.
>
> This caused a 50 k regression in Chromium's binary size due to more
> unrolling. I suspect it's something we'll have to take, but was
> wondering if you have any numbers showing performance benefit here?
>
> Thanks,
> Hans
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141120/2bfc35ca/attachment.html>