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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191113/510cb075/attachment.html>
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, >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/aff170a6/attachment.html>
What are you querying the alias analysis on in the above example - between the load and store? How are you creating your MemoryLocation for those too? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/96ab958d/attachment.html>