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

[Chandler Carruth]

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, 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141120/8bc76f54/attachment.html>