[llvm-commits] [patch] ThreeStageLoopUnroll

Devang Patel dpatel at apple.com
Tue Sep 27 14:25:14 PDT 2011


Daniel,

On Sep 23, 2011, at 11:07 AM, Daniel Nicácio wrote:

> This Patch improves the LoopUnroll Pass. 
> 
> First it identifies special cases where a three stage loop unrolling is desired. For example, if a loop updates an unaligned region of a bit array, it is desired that this pass generates a first loop that updates just some bits on the first word, a main loop that updates all intermediate words and a final loop that updates just some bits on the last word. This way, the main loop can be made canonical and further optimized.
> 
> After splitting the loop into the three stage loops, it unrolls the main loop by a factor of 32, 64 or any other number that can generate further optimization opportunities. Hopefully, those optimizations will collapse the unrolled loop into a more efficient and smaller loop.
> 
> This first version simply identifies loops that contain a "lshr X, 5" or "lshr X, 6" instruction and the result of that instruction is used to index an array.
> 
> The heuristic to find loop candidates for this special unrolling can (and must) be further improved, since this special three stage unrolling is going to be very useful for vectorization passes and can also be used in other cases, like a memcopy and so on.
> 
> The very purpose of this first patch is to get a feedback from the community on the idea of the three stage loop unrolling. Comments and Critics are very welcome.

1)  Please don't update loop structure to keep track of a transformation specific data. It is best to let transformation pass handle isThreeStageUnrollCandidate (), getToBeThreeStageUnrolled() and setToBeThreeStageUnrolled() etc...

2) General llvm convention is to avoid

+  bool candidate = L->isThreeStageUnrollCandidate(L, LI);
+  if(candidate) {
….

and do

+  if (bool candidate = … ) {
+  }

if candidate is not used outside "if".

3) +    static IRBuilder<> Builder(context);

Please avoid using static variables.

4) I have not looked at your implementation in detail, but I'd refactor it properly instead of extending llvm::UnrollLoop() directly.

Are you able to measure performance improvements using this transformation ?

-
Devang
> The next step is going to make the code much more generic.



> 
> Thanks
> 
> Daniel Nicacio
> 
> ps: I still have to come up with a simpler test case, it is in my TODO list ;)
> 
> 
> <threeStageUnroll.diff>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits





More information about the llvm-commits mailing list