[llvm-dev] Question on TBAA and optimization

[Venkataramanan Kumar via llvm-dev]

Can someone clarify on this please?

On Thu, 28 Nov 2019 at 21:58, Venkataramanan Kumar <
venkataramanan.kumar.llvm at gmail.com> wrote:

> 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/20191202/b377d842/attachment.html>