[PATCH] Loop Rerolling Pass

[Hal Finkel]

----- Original Message -----
> 
> 
> 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 :-)

I completely understand; rerolling helps in practice:

 - When compiling code with manually-unrolled loops where the unrolling factor was tuned for some architecture which is unknown, may no longer be relevant, and often both. A classic "legacy code" problem.

 - Where the manually unrolling would interfere with other loop transformations (vectorization is a prime example, but permutation, tiling, skewing, interchange, etc. are also potentially relevant here).

Personally, I think that the 'right' way to manually express an unrolling preference is using some '#pragma unroll(n)' syntax. That this is non-standard is obviously a drawback. Nevertheless, so is almost all other optimizer interaction.

I think that it is important to keep in mind that this only can undo trivial unrolling. If the loop was manually unrolled because non-trivial dependencies would have prevented the compiler from doing so, then those same dependencies should prevent the rerolling. Nevertheless, this does assume that the backend will also unroll when useful (and LLVM has some interesting unrolling capabilities that are not used by default on x86, specifically partial unrolling for non-vectorizable loops, and some work should probably be done in this area).

All that having been said, we may not want this functionality in its present form in the default optimization pipeline. We probably should do it by default when compiling for code size. Otherwise, we may want to use it as a utility function from the loop vectorizer (and other relevant loop transformations) so that we only reroll if we'll be doing something non-trivial with the result.

Thanks,
Hal

> 
> 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
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

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