[PATCH] D68515: [PATCH 31/38] [noalias] SROA/PromoteMemoryToRegister: Learn how to handle noalias intrinsics

[Alexey Zhikhartsev via Phabricator via llvm-commits]

alexey.zhikhar added a comment.

In D68515#1872588 <https://reviews.llvm.org/D68515#1872588>, @jeroen.dobbelaere wrote:

> Is the bitcast introduced by 'clang' (frontend), or was it introduced by one of the optimization passes ? In the latter case, which pass is this?  We should probably handle it and
>  treat it as a 'gep with all-0 indices'... And make sure that the pointer-type for the llvm.noalias is somewhat usable.
>
> If it is based on 'a pointer to int' conversion in the c-language, then it should be ok to just ignore it.


I looked into it, it is instruction combining that introduces the bitcasts. IR before:

  %2 = call %"struct.std::_Array"* @"llvm.noalias.copy.guard.p0s_struct.std::_Arrays.p0i8"(%"struct.std::_Array"* %_M_array4, i8* null, metadata !13, metadata !2)
  %3 = bitcast %"struct.std::_Array"* %_M_array to i8*
  %4 = bitcast %"struct.std::_Array"* %2 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %3, i8* align 4 %4, i32 4, i1 false)

IR after:

  %2 = call %"struct.std::_Array"* @"llvm.noalias.copy.guard.p0s_struct.std::_Arrays.p0i8"(%"struct.std::_Array"* nonnull %_M_array4, i8* null, metadata !44, metadata !47)
  %3 = bitcast %"struct.std::_Array"* %2 to i32*
  %4 = bitcast %"struct.std::_Array"* %_M_array to i32*
  %5 = load i32, i32* %3, align 4
  store i32 %5, i32* %4, align 4

I'm trying to understand your suggestion of treating this kind of bitcasts as a zero-offset GEP, how would we insert an `llvm.noalias` intrinsic? The first operand of `llvm.noalias` obviously should be a pointer but the `load` above doesn't return a pointer, it returns an `i32`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68515/new/

https://reviews.llvm.org/D68515