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

[Hal Finkel]

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at gmail.com>
> To: "Hans Wennborg" <hans at chromium.org>, "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Philip Reames" <listmail at philipreames.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>, "Nico Weber"
> <thakis at chromium.org>
> Sent: Thursday, November 20, 2014 3:39:46 PM
> Subject: Re: [llvm] r219517 - This patch de-pessimizes the calculation of loop trip counts in
> 
> On Thu, Nov 20, 2014 at 12:50 PM, Hans Wennborg < hans at chromium.org >
> wrote:
> 
> 
> On Thu, Nov 20, 2014 at 12:20 PM, Philip Reames
> < listmail at philipreames.com > wrote:
> > 
> > On 11/20/2014 12:07 PM, Mark Heffernan wrote:
> > 
> > Rolling back this CL which just improves analysis precision (trip
> > count
> > computation specifically) is probably not the right approach.
> > 
> > Strongly, strongly agreed with this point.
> 
> Right, I wasn't suggesting that we roll back. I'm not that
> revert-trigger happy :)
> 
> I just wanted to report our binary size findings and was curious to
> hear more from Mark about his commit.
> 
> I agree that this mostly seems like a bug fix, and if we have
> problems
> with unrolling we should probably look at the thresholds. In an ideal
> world our builds should be guided by profiles, but we're not there
> yet.
> I don't think this is the root of the issue.
> 
> 
> 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.
> 
> 
> 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

We should, but it won't help the problem of fully-unrolled code right now (it only deals with making partially-unrolled loops no longer partially unrolled). Maybe we should have a pass to deal with fully-unrolled sequences, but we don't yet.

 -Hal

>, 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?

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory