[PATCH] D104203: [LoopUnroll] Fold all exits based on known trip count/multiple

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D104203#2820498 <https://reviews.llvm.org/D104203#2820498>, @reames wrote:

> I think there's a problem with this code, but I'm surprised the existing test didn't catch it.  Have you run this with explicit dom tree and loop info validation enabled?
>
> Here's the problem I think I see.  If we have an exit block which exits only on iteration X, and we unroll by count Y where Y > X, I believe we'll end up making the exit block unreachable.  (This can't happen if there's only a single exit since that exit must be reached.)  The problem with an unreachable exit is that there can be arbitrarily complicated loops reachable only through that path, and updating loop info in that case is hard.  Am I missing something here?

There's two bits of subtlety here: 1. For non-latch blocks, we don't fold branches towards exit (only towards loop) and 2. for a complete unroll, we always report the last iteration as exiting. These two properties ensure that we don't run into any of the hard LI invalidation scenarios, because we always retain both a branch to all exits (on the last iteration) and all loop blocks, even if we know that one or the other may be unreachable.



================
Comment at: llvm/lib/Transforms/Utils/LoopUnroll.cpp:747
+    if (RuntimeTripCount) {
+      // When runtime unrolling, information about non-latch exits may be
+      // stale.
----------------
reames wrote:
> This bit doesn't make sense to me, can you explain?
The runtime loop unrolling code may insert a prologue, in which case the computed trip counts for the original loop may no longer be correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104203