llvm dev - Oct 2017 - Possible bug of Alias Analysis?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aa-bug.ll
Type: application/octet-stream
Size: 4090 bytes
Desc: aa-bug.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171017/cc4524a1/attachment.obj>

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>

2017-10-17 8:45 GMT+02:00 Song, Ruiling <ruiling.song at
intel.com>:
> 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?
Your tbaa metadata suggests that the two locations cannot alias. Since
they still alias, the metadata is wrong. It looks like you are using a
plain cast between int/float pointers, which is illegal in C (6.5/7)
and in OpenCL (6.1.8). Try using -fno-strict-aliasing to avoid
emitting tbaa metadata.

Michael

> -----Original Message-----
> From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On
> Behalf Of Michael Kruse
> Sent: Tuesday, October 17, 2017 3:26 PM
> To: Song, Ruiling <ruiling.song at intel.com>
> Cc: llvm at meinersbur.de; llvm-dev at lists.llvm.org
> Subject: Re: Possible bug of Alias Analysis?
> 
> 2017-10-17 8:45 GMT+02:00 Song, Ruiling <ruiling.song at intel.com>:
> > 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?
> 
> Your tbaa metadata suggests that the two locations cannot alias. Since
> they still alias, the metadata is wrong. It looks like you are using a
> plain cast between int/float pointers, which is illegal in C (6.5/7)
> and in OpenCL (6.1.8). Try using -fno-strict-aliasing to avoid
> emitting tbaa metadata.
Thanks for the explanation. I think I get your point.
In fact the plain cast was introduced during expanding intrinsic llvm.memcpy().
As on our platform, 4byte copy is more efficient. So if we can, we will try to
cast arguments to llvm.memcpy to 'pointer of int' type no matter what
the type of the pointers passed in.
if we have to disable TBAA to solve the issue, then looks like we have to
completely disable TBAA through the whole compilation of any OpenCL program.
I am not if you can share more insight on expanding the llvm.memcpy() and
keeping the TBAA information correct?

Ruiling
> 
> Michael