Updated deleteDeadLoop() to handle loop nest.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The deleteDeadLoop function when called on the outer loop will effectively remove the subloops from the CFG too (make them unreachable). Maybe we should change deleteDeadLoop to also take the subloops into account when updating the analysis passed to it. Then we shouldn't need a separate function to delete loop nests.
Didn't notice Bardia already posted something similar.
Actually we can do a small modification in deleteDeadLoop to have it works for loop nest, by changing the last line from LI->erase(L); to erasing all loops in L. Would that way be more preferable?
What does everyone think? Is deleteDeadLoop() intensionally work for innermost loops? Is adding deleteDeadLoopNest() or modifying deleteDeadLoop() to work for loops with any depth preferred?
I slightly tend towards @bmahjour's suggestion, for convenience of the user.
Since deleteDeadLoop also deletes all its interior already, what is missing to be correct for nested loops as well? Even SCEV->forgetLoop seems to considered nested loops.
what is missing to be correct for nested loops as well?
The only think I can see missing is LI->erase(L), which relink the subloops of L to the parent of L, or change them to top level loops if L has no parent.
llvm/lib/Transforms/Utils/LoopUtils.cpp | ||
---|---|---|
676 | [remark] Assigning a lambda to a std::function introduces a lot of overhead. However, auto doesn't work for calling itself recursively. https://laptrinhx.com/recursive-lambdas-713741980/ has a nice technique though. | |
677 | [serious] LoopInfo::erase is designed to modify the parent's subloop list. At least, it will remove Subloop from L's subloop list, hence invalidating the iterator we are currently iterating over. | |
681 | [suggestion] Could you add a comment such as "Recursively remove all subloops. Calling LoopInfo::erase only on the dead loop only moves its subloops to the dead loop's parent". LoopInfo::erase does a loot of work to move the association of the subloop blocks to the parent. Since we know that the loop is dead, I wonder whether it is worth introducing a variant that just removes the dead loop from its parent's child list. | |
llvm/unittests/Transforms/Utils/LoopUtilsTest.cpp | ||
28 | [style] No almost always auto |
[remark] Assigning a lambda to a std::function introduces a lot of overhead. However, auto doesn't work for calling itself recursively. https://laptrinhx.com/recursive-lambdas-713741980/ has a nice technique though.