[PATCH] D108910: [IndVars] Break backedge and replace PHIs if loop exits on 1st iteration

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 27 11:32:38 PDT 2021


reames added a comment.

In D108910#3005884 <https://reviews.llvm.org/D108910#3005884>, @mkazantsev wrote:

> @reames I don't quite get the 2nd part of the revert motivation. Leaving it to loop deleiton is cool if there will be loop deletion. Branching out of loop looks better because SimplifyCFG can deal with it.  Why would anything be better than leaving the loop (and potentially breaking it for further passes)? Any examples of this?

Max,

Sorry for delayed response, I apparently forgot to reply to this before leaving for vacation.  My apologizes.

My second point is really two questions:

1. Why do we need to fold these branches to constants at all?  We've already proven that a dominating exit was taken, and thus the code being modified in this change is provably unreachable.  I'd expect existing passes (SimplifyCFG, LoopDeletion, etc..) to handle the current form without issue.  Do you have a case where this change actually effects the output after say simplify-cfg?  I'd not expect that, and it almost seems like you might be covering up a missing transform elsewhere.
2. Given we're dealing with unreachable code, why fold to untaken?  Why not be more aggressive about identifying the explicit UB?  Replacing terminators with "unreachable" would require non-trivial analysis update, so I get not doing that.  But why not replace the condition with an explicit "poison"?  That would be trivially immediate UB, and likely "clearer" for simplify-cfg and friends.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108910



More information about the llvm-commits mailing list