[llvm-dev] TBAA question

[Venkataramanan Kumar via llvm-dev]

Hi  Neil,

The Original IR is obtained from spec2017 benchmark. I will try to reduce
it to a test case and send.
 The "null" value is stored to a pointer variable after calling "free" for
the allocated memory.   The type of the pointer is bitcasted to i8** before
storing "null".

TBAA seem to represent pointer field "next" as "any pointer" in the below
example.

---Snip--
struct st {
int a;
struct st * next;
};

struct st *ptr;
ptr->next = null

 %next = getelementptr inbounds %struct.st, %struct.st* %ptr, i64 0, i32 1
  store %struct.st* null, %struct.st** %next, align 8, !tbaa !2

!2 = !{!3, !7, i64 8}
!3 = !{!"st", !4, i64 0, *!7*, i64 8}
!4 = !{!"int", !5, i64 0}
!5 = !{!"omnipotent char", !6, i64 0}
!6 = !{!"Simple C/C++ TBAA"}
!7 = !{!"any pointer", !5, i64 0}
--Snip--

TBAA will say "may alias" if it finds second store which has* !7* attached
, i.e  any general pointer store ?
It will not consider the context from where the second store  is coming (
it may be bitcasted from a different struct * to i8**).

regards,
Venkat.




On Fri, 15 Nov 2019 at 22:46, Neil Henning <neil.henning at unity3d.com> wrote:

> I'd need to see more of the IR if you could provide it to give a guess at
> the problem!
>
> On Fri, Nov 15, 2019 at 4:49 PM Venkataramanan Kumar <
> venkataramanan.kumar.llvm at gmail.com> wrote:
>
>> Hi Neil
>>
>> On Fri, 15 Nov 2019 at 15:26, Neil Henning <neil.henning at unity3d.com>
>> wrote:
>>
>>> What are you querying the alias analysis on in the above example -
>>> between the load and store?
>>>
>>
>> I am interested to check if  the load "%2" is not changed inside the
>> function (assuming there are no function calls).  I am checking to see if
>> there are any store instructions in that function that could aliases  and
>> modify the load.
>>
>>
>>
>>> How are you creating your MemoryLocation for those too?
>>>
>>
>> I query using alias method as shown below.
>>
>> MemoryLocation Locld = MemoryLocation::get(Loadinst);
>> MemoryLocation Locst = MemoryLocation::get(Storeinst);
>>
>> if (AA->alias(Loc,Locst) != llvm::NoAlias ) {
>> ==> it reaches here
>> }
>>
>> Also checked modref info.
>> if(isModSet(AA->getModRefInfo(Storeinst, Loc))
>> {
>> ==> it reaches here
>> }
>>
>> regards,
>> Venkat,
>>
>>>
>>> On Fri, Nov 15, 2019 at 6:03 AM Venkataramanan Kumar via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Can someone  please clarify me on this?
>>>>
>>>>
>>>>
>>>> On Wed, 13 Nov 2019 at 22:25, Venkataramanan Kumar <
>>>> venkataramanan.kumar.llvm at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have the following LLVM IR.
>>>>>
>>>>> ----Snip---
>>>>> %1 = getelementptr inbounds %struct._X, %struct._X* %0, i64 0, i32 3
>>>>> %2 = load %struct._X*, %struct._X** %1, align 8, !tbaa !10
>>>>> ....
>>>>> .....
>>>>> .......
>>>>>
>>>>> %3 = bitcast %struct._Y** %1 to i8**
>>>>> store i8* null, i8** %3, align 8, !tbaa !9
>>>>>
>>>>> !9 = !{!7, !7, i64 0}
>>>>> !7 = !{!"omnipotent char", !8, i64 0}
>>>>> !8 = !{!"Simple C/C++ TBAA"}
>>>>>
>>>>> ----Snip----
>>>>>
>>>>> Load inst above is trying to access a field of _X which is a self
>>>>> recursive pointer to same struct _X.
>>>>> Store puts a null value for a pointer to struct _Y. It has been
>>>>> bitcasted to i8** and store happens via char pointer.
>>>>>
>>>>>
>>>>> When I query alias analysis although loads and stores are pointers to
>>>>> different struct types. TBAA says may alias.
>>>>> is it safe to assume the loaded pointer to struct _X do not alias with
>>>>> the store , if we look further at bitcast and see the pointer to different
>>>>> struct?
>>>>>
>>>>> is my understanding wrong here?
>>>>>
>>>>> 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
>>>
>>
>
> --
> Neil Henning
> Senior Software Engineer Compiler
> unity.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/328547f4/attachment.html>