[PATCH] D50497: [AliasSetTracker] Do not treat experimental_guard intrinsic as memory writing instruction

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev added inline comments.


================
Comment at: test/Analysis/AliasSet/intrinsics.ll:21
+; CHECK: Alias Set Tracker: 3 alias sets for 2 pointer values.
+; CHECK:   AliasSet[0x{{[0-9a-f]+}}, 1] must alias, Mod       Pointers: (i8* %a, 1)
+; CHECK:   AliasSet[0x{{[0-9a-f]+}}, 1] may alias, Ref
----------------
reames wrote:
> Ah, not sure what went wrong here, but this output is wrong.  a, and b, must be in the same AliasSet as the guard.  Both a and b modify memory read by the guard.   (Unless, this might be specific to allocas which are thread local...  if so, you need testing for the case where a and b are not alloca!)
My best guess is that locally allocated objects never alias. I will add more tests to see what happens.


================
Comment at: test/Analysis/AliasSet/intrinsics.ll:25
+; CHECK:   AliasSet[0x{{[0-9a-f]+}}, 1] must alias, Mod       Pointers: (i8* %b, 1)
+define void @test2(i32 %c) {
+entry:
----------------
reames wrote:
> You can simplify this by making the argument the i1.
I can, but I just copied it from the test above to clearly show the output difference.


https://reviews.llvm.org/D50497