[llvm-dev] Question on TBAA and optimization

Venkataramanan Kumar via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 3 04:39:19 PST 2019


Sure I will create a PR for this.
regards,
Venkat.

On Tue, 3 Dec 2019 at 15:02, Neil Henning <neil.henning at unity3d.com> wrote:

> I can reproduce your results - its not forwarding the load from the
> previous store. I'm not sure why but none of the alias analysis passes are
> detecting that the two GEPs do not alias (they always come out as MayAlias)
> and I think its abandoning doing the store forwarding as a result.
>
> You might want to file a bug for this?
>
> Cheers,
> -Neil.
>
> On Mon, Dec 2, 2019 at 3:41 PM Venkataramanan Kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> --
> Neil Henning
> Senior Software Engineer Compiler
> unity.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191203/5a1fcde4/attachment.html>


More information about the llvm-dev mailing list