In the original implementation, it did not check if the loop latches are tightly nested. We added the checking on if the latches are tightly nested.
Diff Detail
Event Timeline
llvm/lib/Analysis/LoopNestAnalysis.cpp | ||
---|---|---|
132 | If there are multiple induction phi, how can we know the first one encountered is the induction phi used for the loop bound? | |
135 | This change the current definition of perfect loop nest. | |
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
950 | Have you considered using if (LN.getMaxPerfectDepth() != InnerLoop->getLoopDepth())? |
llvm/lib/Analysis/LoopNestAnalysis.cpp | ||
---|---|---|
135 | I think LoopInterchange uses a slightly more relaxed 'tightly nested' criteria. How much work would it be to check that the path from inner loop exit to outer loop latch? | |
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
610 | are those checks included in the new checks? |
llvm/test/Transforms/LoopInterchange/perfectly-nested.ll | ||
---|---|---|
11 ↗ | (On Diff #305985) | The name of this file perfectly-nested.ll is counter-intuitive because you have an imperfect loop nest in this file. Name the file "imperfectly-nested.ll" ? |
llvm/lib/Analysis/LoopNestAnalysis.cpp | ||
---|---|---|
126 | I think that removing this restriction (allow binary operators that have loop invariant values) is not necessary and would make the definition of a perfect loop nest too loose. In order to handle a loop with binary opcodes that have loop invariant values in the inner loop you could add a transformation that sink that instruction into the inner loop (therefore making the resulting loop nest perfect). Then loop interchange will be able to handle the resulting perfect loop nest. |
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
---|---|---|
578–579 | Is there a reason to rename Outer->Parent and Inner->Child? As all the comments still use the term inner and outer to reference the loops. | |
946–964 | processLoop is called with loop i and i -1, so there are no loops in between InnerLoop and OuterLoop. |
https://reviews.llvm.org/D98263 covered some of this change now, can you please rebase the patch?
The test case LGTM. Thanks.
I think that removing this restriction (allow binary operators that have loop invariant values) is not necessary and would make the definition of a perfect loop nest too loose.
In order to handle a loop with binary opcodes that have loop invariant values in the inner loop you could add a transformation that sink that instruction into the inner loop (therefore making the resulting loop nest perfect). Then loop interchange will be able to handle the resulting perfect loop nest.