[llvm-dev] TBAA for struct fields

[Tiwary, Siddharth via llvm-dev]

[AMD Official Use Only - Internal Distribution Only]

Hi,

Following issue is observed with Type Based Alias Analysis(TBAA).

#######################################################
struct P {
  float f1;
  float f2;
  float f3[3];
  float f4;
};

void foo(struct P* p1, struct P* p2) {
  p1->f2 = 1.2;
  p2->f1 = 3.7;
}

int callFoo() {
  struct P p;
  foo(&p, &(p.f2));
}
######################################################

Printing alias-sets using commands:

  clang -O1 -S -emit-llvm struct_tbaa.c
  opt -basicaa -tbaa -print-alias-sets -disable-output struct_tbaa.ll

yields:

Alias sets for function 'foo':
Alias Set Tracker: 2 alias sets for 2 pointer values.
  AliasSet[0x563d8f6a8bd0, 1] must alias, Mod       Pointers: (i32* %f2, LocationSize::precise(4))
  AliasSet[0x563d8f6bc080, 1] must alias, Mod       Pointers: (float* %f1, LocationSize::precise(4))

IR of foo:

; Function Attrs: nofree norecurse nounwind uwtable writeonly
define dso_local void @foo(%struct.P* nocapture %p1, %struct.P* nocapture %p2) local_unnamed_addr #0 {
entry:
  %f2 = getelementptr inbounds %struct.P, %struct.P* %p1, i64 0, i32 1
  store float 0x3FF3333340000000, float* %f2, align 4, !tbaa !2
  %f1 = getelementptr inbounds %struct.P, %struct.P* %p2, i64 0, i32 0
  store float 0x400D9999A0000000, float* %f1, align 4, !tbaa !7
  ret void
}
!2 = !{!3, !4, i64 4}
!3 = !{!"P", !4, i64 0, !4, i64 4, !5, i64 8, !4, i64 20}
!4 = !{!"float", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C/C++ TBAA"}
!7 = !{!3, !4, i64 0}

TBAA returns p1->f2 and p2->f1 in different alias-sets. But p1->f2 and p2->f1 do actually have the same address! Shouldn't the alias result be conservative while doing TBAA, especially when it needs interprocedural analysis?
If instead of the above, p1->f2 and p2->f2 are the ones being accessed, then p1->f2 and p2->f2 are returned in same alias-sets. So, in second case, it is indeed conservative!

Could someone please explain the rationale behind above behavior?

Thanks,
Siddharth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200227/2a0136cb/attachment.html>