[llvm-dev] Possible bug of Alias Analysis?

[Ivan Kosarev via llvm-dev]

Hello Ruiling,

So BasicAA cannot determine for sure if two accesses overlap and lets 
TBAA to say if they are allowed to overlap by the rules on the input 
language. The IR code and TBAA decoration looks like you are trying to 
write a buffer as an array of ints and read it as an array of floats 
without use of unions. If so, then this code violates aliasing rules and 
should not be compiled with TBAA enabled.


On 17/10/17 09:45, Song, Ruiling via llvm-dev wrote:
> Hi,
>
> I am an out-of-tree user of llvm. I am running into an regression issue against llvm 5.0.
> The issue was introduced by "[BasicAA] Use MayAlias instead of PartialAlias for fallback."( https://reviews.llvm.org/D34318)
> I have attached a very simple program to reproduce the issue. The symptom is alias analysis report NoAlias to GVN which cause GVN do wrong optimization.
> The BasicAA reports MayAlias while TBAA reports NoAlias, when query the pointers of below two instructions in attached sample:
> %5 = load float, float addrspace(4)* %add.ptr.i5, align 4, !tbaa !13
> store i32 %3, i32* %4, align 4, !tbaa !3
> but in fact, they should be aliased as they are writing to/reading from the same buffer.
>
> you can run 'opt -S -aa -basicaa -tbaa -gvn aa-bug.ll -o -' to see what happens.
> I am not sure if we use llvm wrong or is it a bug that we should fix in llvm?
>
> Thanks!
> Ruiling
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171017/ab002087/attachment.html>