Surprising TBAA result with struct access tag

Hi,

I’m trying to understand a surprising result from type-based alias analysis. The bitcode below accesses two memory locations for which TBAA should, I think, conclude MayAlias:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define void @test(ptr %a, ptr %b) {
  store i32 0, ptr %a, !tbaa !0
  %1 = load { i32, i32 }, ptr %b, !tbaa !4
  ret void
}

!0 = !{!1, !1, i64 0, i64 4}
!1 = !{!3, i64 4, !"A"}
!3 = !{!"Root"}
!4 = !{!5, !5, i64 0, i64 8}
!5 = !{!3, i64 8, !"struct", !6, i64 0, i64 4, !6, i64 4, i64 4}
!6 = !{!1, i64 4, !"B"}

However:

$ opt -aa-pipeline=tbaa -passes=aa-eval -evaluate-aa-metadata -print-no-aliases -print-may-aliases -disable-output test.ll
[...]
  NoAlias:   %1 = load { i32, i32 }, ptr %b, align 4, !tbaa !3 <->   store i32 0, ptr %a, align 4, !tbaa !0
[...]

Is my metadata wrong? Or is the struct access tag unsupported? There is a test that makes me think this should work with new-format tags. Or is the scalar type chain B -> A -> Root a problem?

Any hints are greatly appreciated!

Thanks,
Sebastian

1 Like