[PATCH] D50497: [AliasSetTracker] Do not treat experimental_guard intrinsic as memory writing instruction
Max Kazantsev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Aug 12 18:37:33 PDT 2018
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
More information about the llvm-commits
mailing list