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 | ||
---|---|---|
126 ↗ | (On Diff #305985) | If there are multiple induction phi, how can we know the first one encountered is the induction phi used for the loop bound? |
129 ↗ | (On Diff #305985) | This change the current definition of perfect loop nest. |
llvm/lib/Transforms/Scalar/LoopInterchange.cpp | ||
1025 | Have you considered using if (LN.getMaxPerfectDepth() != InnerLoop->getLoopDepth())? |
llvm/lib/Analysis/LoopNestAnalysis.cpp | ||
---|---|---|
129 ↗ | (On Diff #305985) | 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 ↗ | (On Diff #306382) | 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 | ||
---|---|---|
590–591 | 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. | |
1021 | 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.
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.