[all-commits] [llvm/llvm-project] ef51ee: [LoopDeletion] Handle inner loops w/untaken backedges
Philip Reames via All-commits
all-commits at lists.llvm.org
Fri Jan 22 16:48:45 PST 2021
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: ef51eed37b7ed67b3c0e5f70fa61d681ba21787d
https://github.com/llvm/llvm-project/commit/ef51eed37b7ed67b3c0e5f70fa61d681ba21787d
Author: Philip Reames <listmail at philipreames.com>
Date: 2021-01-22 (Fri, 22 Jan 2021)
Changed paths:
M llvm/lib/Transforms/Scalar/LoopDeletion.cpp
M llvm/lib/Transforms/Utils/LoopUtils.cpp
M llvm/test/Transforms/IndVarSimplify/X86/pr45360.ll
M llvm/test/Transforms/LoopDeletion/zero-btc.ll
Log Message:
-----------
[LoopDeletion] Handle inner loops w/untaken backedges
This builds on the restricted after initial revert form of D93906, and adds back support for breaking backedges of inner loops. It turns out the original invalidation logic wasn't quite right, specifically around the handling of LCSSA.
When breaking the backedge of an inner loop, we can cause blocks which were in the outer loop only because they were also included in a sub-loop to be removed from both loops. This results in the exit block set for our original parent loop changing, and thus a need for new LCSSA phi nodes.
This case happens when the inner loop has an exit block which is also an exit block of the parent, and there's a block in the child which reaches an exit to said block without also reaching an exit to the parent loop.
(I'm describing this in terms of the immediate parent, but the problem is general for any transitive parent in the nest.)
The approach implemented here involves a potentially expensive LCSSA rebuild. Perf testing during review didn't show anything concerning, but we may end up needing to revert this if anyone encounters a practical compile time issue.
Differential Revision: https://reviews.llvm.org/D94378
More information about the All-commits
mailing list