[llvm-dev] Possible bug of Alias Analysis?

[Song, Ruiling via llvm-dev]

> -----Original Message-----
> From: Ivan Kosarev [mailto:ikosarev at accesssoftek.com]
> Sent: Wednesday, October 18, 2017 3:05 PM
> To: Song, Ruiling <ruiling.song at intel.com>
> Cc: Michael Kruse <llvmdev at meinersbur.de>; llvm-dev at lists.llvm.org; Michael
> Kruse <llvm at meinersbur.de>
> Subject: Re: [llvm-dev] Possible bug of Alias Analysis?
> 
> Dereferences of int pointers should normally be decorated with !tbaa
> nodes that describe accesses to "int" objects.
> 
> In your case where don't really transfer int objects you can ask the
> compiler to treat the accesses as may-alias ones, like this:
> 
> typedef int __attribute__((may_alias)) AI;
> 
> void copy_by_ints(AI *dest, const AI *src, size_t n) {
>    for (size_t i = 0; i != n; ++i)
>      dest[i] = src[i];
> }

I tried this method, it works for my problem. The 'may_alias' let clang generate tbaa metadata for the instruction as ("omnipotent char").

Thanks!
Ruiling
> 
> 
> On 18/10/17 09:10, Song, Ruiling via llvm-dev wrote:
> >
> >> -----Original Message-----
> >> From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com]
> On
> >> Behalf Of Michael Kruse
> >> Sent: Wednesday, October 18, 2017 1:18 PM
> >> To: Song, Ruiling <ruiling.song at intel.com>
> >> Cc: Michael Kruse <llvm at meinersbur.de>; llvm-dev at lists.llvm.org
> >> Subject: Re: Possible bug of Alias Analysis?
> >>
> >> 2017-10-18 4:48 GMT+02:00 Song, Ruiling <ruiling.song at intel.com>:
> >> ...
> >> 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.
> > May be I need to tell you how we handle @llvm.memcpy in details for you to
> clearly understand the reason behind the issue.
> > We provide a pre-built library function declared as __custom_memcpy(char
> *dst, char*src). This function was compiled into library.bc.
> > Inside the __custom_memcpy(char* dst, char *src), we need to cast the
> pointer to int* to get optimal IO performance. Which breaks TBAA.
> > And user provided OpenCL program was compiled as another module named
> opencl.bc. Then we link opencl.bc and library.bc together.
> > Then we use a custom lowering pass which directly replace intrinsic
> @llvm.memcpy into a call to the library function __custom_memcpy().
> > And after that a function-inline pass was running over the module. Through
> this way, we successfully lowered @llvm.memcpy into store/load instructions.
> > I am not sure whether I have described the process clear?
> >
> > So based on your message, "when converting to load/store. They should point
> to ("omnipotent char")."
> > As we are using 'int *' to get optimal performance when lowering
> llvm.memcpy to load/store.
> > Do you mean that the tbaa for that 'int *' load/store should point to
> ("omnipotent char")." Am I right?
> >
> > Ruiling
> >> Michael
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev