[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:44:36 PST 2021


  Branch: refs/heads/main
  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