[PATCH] D46044: [LoopUnrollPeel] Fix potentially incorrect invalidation of SCEV in peelLoop

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 13 10:09:02 PST 2019


fhahn added a comment.
Herald added a subscriber: jdoerfert.

In D46044#1388382 <https://reviews.llvm.org/D46044#1388382>, @mkazantsev wrote:

> Hi Florian,
>
> If you take a look at `computeBackedgeTakenCount` method, it constructs `BackedgeTakenInfo` that contains references on loop's exiting blocks inside. This info is then cached in `BackedgeTakenCounts`. If we change an inner loop so that one of these blocks gets deleted or stops being exiting, any of its parents may end up keeping dangling pointers to this block (because exiting block of inner loop can also be an exiting block of its parents).


Ah right, Loop peeling currently is restricted to loops with a unique exiting block that is also the loop latch. I am not sure if it is possible to have parent loops that share the peeled loop's exiting block: if there's only one exiting block, the parent loop should be the loop containing the exit block?

But I suppose it would be fine to be cautious here, especially because simplifyLoop already uses forgetTopmostLoop. So maybe just use forgetTopmostLoop here and preserving SE in simplifyLoop should unnecessary.

While playing around with the invalidation here, I found another potential issue: not invalidating when L has no parent. After peeling the exit count of L will have changed -> D58192 <https://reviews.llvm.org/D58192>.


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

https://reviews.llvm.org/D46044





More information about the llvm-commits mailing list