[PATCH] D93906: [LoopDeletion] Break backedge of loops when known not taken

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D93906#2477485 <https://reviews.llvm.org/D93906#2477485>, @nikic wrote:

> In D93906#2476763 <https://reviews.llvm.org/D93906#2476763>, @reames wrote:
>
>> In D93906#2476680 <https://reviews.llvm.org/D93906#2476680>, @nikic wrote:
>>
>>> Isn't this already covered by the zero exit count optimization in IndVars?
>>
>> No.  I believe you're referring to optimizeLoopExits.  That does not modify the CFG, it just folds conditions to constants.  This will specifically modify the CFG and remove the loop.
>
> Yes, that's the transform I had in mind. I see the difference now, but I'm not sure I understand the larger picture / motivation behind this. The true/false branches will get folded away by SimplifyCFG -- so is this a phase ordering problem where SimplifyCFG runs too late (if so, can we add a PhaseOrdering test)? Should we also try to fold away (to unreachable) dead exits, rather than just dead backedges?

You can view this as a phase ordering issue, but really I see it as "this pass is supposed to delete dead loops" + "a case came up in discussion which we'd missed" + "easy no-cost fix".

The phase ordering is magnified by the fact that SimplifyCFG is not a loop pass and thus requires a DT/LI rebuild.  (The in flight DT work for SimplifyCFG looks like it might help there.)

Also, JFYI, deleting dead exits is actually pretty non-trivial (while preserving loop info).  See the code in SimplifyLoopCFG which tries.  The basic problem is that sibling loops can become unreachable when removing any exit edge.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93906/new/

https://reviews.llvm.org/D93906