[llvm-dev] Question on TBAA and optimization

Venkataramanan Kumar via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 28 08:28:34 PST 2019


TBAA Question.

Please consider the following test case.

---Snip--
struct B {
  int b1;
  int b2;
};

struct C {
 int b1;
};

struct A {
 int a1;
 struct C SC;
 int a2;
};

int foo1(struct A * Aptr, struct B* Bptr)
{
   int *a = &Aptr->SC.b1;
   *a=10;
   Bptr->b1 = 11;
   return *a;
}

int foo2(struct A * Aptr, struct B* Bptr)
{
   Aptr->SC.b1=10;
   Bptr->b1 = 11;
   return Aptr->SC.b1;
}
---Snip--

The structure pointers "Aptr" and "Bptr" will not alias each other in both
the functions.
TBAA is able to figure that out in the case of "foo2". Hence it could
propagate the  value "10" directly for return in "foo2".

--IR snippet ---

; Function Attrs: nounwind uwtable
define dso_local i32 @foo1(%struct.A* %Aptr, %struct.B* %Bptr)
local_unnamed_addr #0 {
entry:
  %b1 = getelementptr inbounds %struct.A, %struct.A* %Aptr, i64 0, i32 1,
i32 0
  store i32 10, i32* %b1, align 4, !tbaa !2
  %b11 = getelementptr inbounds %struct.B, %struct.B* %Bptr, i64 0, i32 0
  store i32 11, i32* %b11, align 4, !tbaa !6
  %0 = load i32, i32* %b1, align 4, !tbaa !2 <== reloads from memory.
  ret i32 %0
}

; Function Attrs: nounwind uwtable
define dso_local i32 @foo2(%struct.A* %Aptr, %struct.B* %Bptr)
local_unnamed_addr #0 {
entry:
  %b1 = getelementptr inbounds %struct.A, %struct.A* %Aptr, i64 0, i32 1,
i32 0
  store i32 10, i32* %b1, align 4, !tbaa !8
  %b11 = getelementptr inbounds %struct.B, %struct.B* %Bptr, i64 0, i32 0
  store i32 11, i32* %b11, align 4, !tbaa !6
  ret i32 10 <== returns 10
}
---IR snippet ---

I assume for both cases there is no possibility of memory aliasing. is my
assumption wrong?
Why we are not optimizing the return for function "foo1"?  is that because
TBAA is not formed in that case?

Please clarify.

regards,
Venkat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191128/f85b5296/attachment.html>


More information about the llvm-dev mailing list