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

[Philip Reames via Phabricator via llvm-commits]

reames requested changes to this revision.
reames added a comment.
This revision now requires changes to proceed.

You need much more careful and exhaustive testing.  At minimum, I want to see combinations of multiple guards, load/guard, store/guard, unrelated call/guard, etc..



================
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
----------------
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!)


================
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:
----------------
You can simplify this by making the argument the i1.


https://reviews.llvm.org/D50497