[llvm-dev] TBAA falsely reporting may alias?
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 13 20:45:21 PDT 2017
Hi Kavon,
On April 13, 2017 at 11:31:17 AM, Kavon Farvardin via llvm-dev
(llvm-dev at lists.llvm.org) wrote:
> I'm trying to work with Type Based Alias Analysis (TBAA). Here's the example program
> I'm working with:
>
> ;;;;;;;;;;;;;;;;;;;;;;
>
> define void @foo(i64* %a, i64* %b, i64 %x, i64 %y) {
> store i64 %x, i64* %a, !tbaa !2 ; write to stack
> store i64 %y, i64* %b, !tbaa !3 ; write to heap
> ret void
> }
>
> !1 = !{!"root"}
> !2 = !{!"stack", !1}
> !3 = !{!"heap", !1}
>
> ;;;;;;;;;;;;;;;;;;;;;;
>
> When I run: opt -disable-output -disable-basicaa -tbaa -aa-eval -print-alias-sets
> simple_tbaa.ll
>
> I get something unusual, as the two pointers %a and %b are in disjoint alias sets, but aa-eval
> reports that they may alias:
Given the IR you have, what you know is that the two store
*operations* do not alias, not that %a does not alias %b. In the
specific case above, you can use the information about the stores to
say something about the aliasing between %a and %b, but that's not
true in general of TBAA.
To make -aa-eval also report the aliasing between loads and stores,
you can pass in -evaluate-aa-metadata to opt (along with -aa-eval), in
which case you'll get 1 NoAlias (between the two stores) and one
MayAlias (between the two pointers %a and %b) on the above IR.
-- Sanjoy
More information about the llvm-dev
mailing list