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

[Mark Heffernan]

On Thu, Nov 20, 2014 at 1:39 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> 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.
>

With profile info you'd probably want to treat all cold code as -Os, so if
a constant-trip-count loop is cold you wouldn't unroll because of the code
size bloat.

You're right about this patch exposing more opportunities for the
unroller.  Accordingly, you unfortunately can't really undo its affect by
tweaking thresholds which are applied on a loop-by-loop basis.  In order to
claw back the code size expansion this causes, you'd have to limit the
unrolling size threshold across all loops with unknown performance effects.

Mark


>
> 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?
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141120/acffaf8c/attachment.html>