[PATCH] Loop Rerolling Pass

[Richard Mitton]

Hi,

Surely if someone has manually unrolled a loop, that's a clear intention 
from them that they wanted it to stay unrolled?
In the past I've had to manually unroll loops because the compiler (for 
one reason or other) would refuse to do it itself, and I'd be quite 
annoyed if the compiler decided to undo my work :-)

Richard Mitton
richard at codersnotes.com

On 10/15/2013 12:09 PM, hfinkel at anl.gov wrote:
> Hi nadav, rengolin, atrick,
>
> I've created a loop rerolling pass. The transformation aims to take loops like this:
>
>    for (int i = 0; i < 3200; i += 5) {
>      a[i] += alpha * b[i];
>      a[i + 1] += alpha * b[i + 1];
>      a[i + 2] += alpha * b[i + 2];
>      a[i + 3] += alpha * b[i + 3];
>      a[i + 4] += alpha * b[i + 4];
>    }
>
> and turn them into this:
>
>    for (int i = 0; i < 3200; ++i) {
>      a[i] += alpha * b[i];
>    }
>
> and loops like this:
>
>    for (int i = 0; i < 500; ++i) {
>      x[3*i] = foo(0);
>      x[3*i+1] = foo(0);
>      x[3*i+2] = foo(0);
>    }
>
> and turn them into this:
>
>    for (int i = 0; i < 1500; ++i) {
>      x[i] = foo(0);
>    }
>
> There are two motivations for this transformation:
>
>   1. Code-size reduction (especially relevant, obviously, when compiling for code size).
>
>   2. Providing greater choice to the loop vectorizer (and generic unroller) to choose the unrolling factor (and a better ability to vectorize). The loop vectorizer can take vector lengths and register pressure into account when choosing an unrolling factor, for example, and a pre-unrolled loop limits that choice. This is especially problematic if the manual unrolling was optimized for a machine different from the current target.
>
> The current implementation is limited to single basic-block loops only. The rerolling recognition should work regardless of how the loop iterations are intermixed within the loop body (subject to dependency and side-effect constraints), but the significant restriction is that the order of the instructions in each iteration must be identical. This seems sufficient to capture all of my current use cases.
>
> The transformation triggers very rarely on the test suite (which I think it good, programmers should be able to leave trivial unrolling to the compiler). When I insert this pass just prior to loop vectorization, and prior to SLP vectorization (so that we prefer to reroll over SLP vectorizing), it helps:
>
> On an Intel Xeon E5430:
> MultiSource/Benchmarks/TSVC/LoopRerolling-flt: 36% speedup (loops s351 and s353 are rerolled, s353's performance regresses by 9%, but s351 exhibits a 76% speedup; all others are unchanged)
> MultiSource/Benchmarks/TSVC/LoopRerolling-dbl: 13% speedup (loops s351 and s353 are rerolled, s353's performance is essentially unchanged, but s351 exhibits a 38% speedup; all others are unchanged)
> FreeBench/distray/distray: No significant change
>
> Please review.
>
> Thanks again,
> Hal
>
> http://llvm-reviews.chandlerc.com/D1940
>
> Files:
>    include/llvm-c/Transforms/Scalar.h
>    include/llvm/InitializePasses.h
>    include/llvm/LinkAllPasses.h
>    include/llvm/Transforms/Scalar.h
>    lib/Transforms/Scalar/CMakeLists.txt
>    lib/Transforms/Scalar/LoopRerollPass.cpp
>    lib/Transforms/Scalar/Scalar.cpp
>    test/Transforms/LoopReroll/basic.ll
>
>
> _______________________________________________
> 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/20131015/3acf4afe/attachment.html>