[llvm-dev] Possible bug of Alias Analysis?

[Ivan Kosarev via llvm-dev]

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];
}


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