[PATCH] D91711: SCEV add function to see if SCEVUnknown is null

Markus Lavin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 25 04:10:47 PST 2020


markus added a comment.

In D91711#2415769 <https://reviews.llvm.org/D91711#2415769>, @mkazantsev wrote:

> Do we know at which point LSR deletes the code? To me it looks like we just forgot to call `forgetLoop` or smth like this somewhere.

I have not looked closely where LSR removes the code but I am not sure how that would help.

The point with the debug salvaging we try to do in that pass is that we look at the llvm.dbg.value intrinsics and then compute a SCEV for the value it references. We store that SCEV. Then after the transformation we see if any of the intrinsics now reference undef (remember that debug intrinsics don’t count as real uses and hence predecessors may get deleted). If an intrinsic now references undef we look at its SCEV (that we stored previously). At this point that SCEV for sure represents some IR that has been deleted (well actually rewritten by LSR). The usual case at this point is that the SCEVUnknowns of the SCEV expression are still around. If this is the case we proceed to compare this SCEV of the old value to other SCEVs of things that are around after LSR (e.g. the phi-nodes of the loop header) to see if we can replace the undef reference of the intrinsic with any of these.

So the point is that we expect some of the IR that the SCEV was based on to have been deleted but only the IR that is already captured by the SCEV (i.e. not SCEVUnknown). Does that make any sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91711



More information about the llvm-commits mailing list