[llvm-dev] Possible bug of Alias Analysis?

[Michael Kruse via llvm-dev]

2017-10-18 4:48 GMT+02:00 Song, Ruiling <ruiling.song at intel.com>:
>> -----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?

clang should not have emitted tbaa metadata for the arguments of a
memcpy call. Besides using a union, memcpy is a supported way to copy
bits between unrelated types (since its arguments are void* and can
point to anything). When converting to load/store, these should point
to void*'s metadata ("omnipotent char").

That is, I'd conclude that either the load/store do not originate from
a memcpy, or there is a serious bug.

Michael