[llvm-dev] [RFC] Changing LoopUnrollAndJamPass to a function pass.
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 2 14:48:50 PST 2020
This makes sense to me.
--
Johannes
On 01/02, Whitney T Tsang via llvm-dev wrote:
> LoopUnrollAndJamPass is currently a loop pass. It is added in a LPM with only
> itself.
> `OptimizePM.addPass(createFunctionToLoopPassAdaptor(LoopUnrollAndJamPass
> (Level)));`
> Notice that loops are traversed in an inner to outer order in a LPM.
>
> The current implementation of LoopUnrollAndJamPass supports only loop nest with
> one inner loop (L->getSubLoops().size() == 1).
> Consider the example below:
> Before loop unroll and jam:
> ```
> for i
> for j
> for k
> A[I][j][k] = 0;
> ```
> After loop unroll and jam loop-j with a factor of 2:
> ```
> for i
> for j += 2
> for k
> A[I][j][k] = 0;
> A[I][j+1][k] = 0;
> for j’=j
> for k
> A[I][j][k] = 0;
> ```
> Notice that LoopUnrollAndJamPass can no longer unroll and jam loop-i at the
> next invocation of LoopUnrollAndJamPass, since there exists two inner loops in
> loop-i.
> If LoopUnrollAndJamPass is a function pass, then it can control the order of
> the loops being considered. By doing the transformation from outer to inner,
> both loop-i and loop-j can be unroll and jammed.
>
> In conclusion, I propose to change LoopUnrollAndJamPass from loop to function
> pass, with the reasons below:
> 1. There is no obvious reason why LoopUnrollAndJamPass need to be a loop pass
> 2. More loops can be transformed by traversing in a outer to inter order
> 3. Less remaining loops are needed if we consider the whole loop nest together
> 4. Better cost model can be created by considering the whole loop nest together
>
> Regards,
> Whitney Tsang
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Johannes Doerfert
Researcher
Argonne National Laboratory
Lemont, IL 60439, USA
jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200102/97242597/attachment.sig>
More information about the llvm-dev
mailing list