[PATCH] D40480: MemorySSA backed Dead Store Elimination.

[Daniel Berlin via llvm-commits]

Nope, you are right, part of this is giving up in some cases for removing a
factor of O(uses) from most checks. But there is more to extract from what
it is telling you that *isn't* doing that.


Remember that what it's really telling you is that "any def in between the
use and the def it's linked to is no-alias of the use".

So, given, for example:

define i32 @test(i32* %P, i32 %y) {
; 1 = MemoryDef(liveOnEntry)
  store i32 1, i32* %P
  %Py = getelementptr i32, i32* %P, i32 %y
; 2 = MemoryDef(1)
  store i32 2, i32* %Py
; 3 = MemoryDef(2)
  store i32 1, i32* %P
  %P1 = getelementptr i32, i32* %P, i32 1
; MemoryUse(2)
  %l = load i32, i32* %P1
  ret i32 %l
}


This proves that MemoryUse(2) cannot affect the store at 1.  If it could,
it would have been MemoryUse(3) instead.
MemorySSA already figured this out for you, and currently, you will
rediscover it.  In fact, it's better than that, because in just about all
cases outside of the pair metadata i referred to earlier, seeing this
proves it "for all time" (IE you don't have to ever forget this information)

IE your statement " If SI->Current is NoAlias we can't safely treat SI->Use
as noalias though."

This is true in general, but false if a store with the same loc is in
between Si->Use and SI->getDefiningAccess()

You can use OrderedInstructions or something to see if that's the case.

So basically all i'm asking is that you use the information it's providing
you if you can :)
The information it's providing is that "given a use, the use may/must alias
with it's def. Anything in between the use and it's current def must be
noalias".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171204/d7867182/attachment.html>