[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.

Jeroen, we discovered an assertion in `introduceNoAliasWhenCopyGuardIndicesAreCompatible()` for the case described below; we would appreciate your input.

This function expects a GEP between a `load` and a `copy.guard`, however, it's not always so; consider the following case where there's a `bitcast` instruction instead:

  %3 = call %struct.FOO* @llvm.noalias.copy.guard.p0s_struct.FOOs.p0i8(%struct.FOO* %ssrc, i8* %0, metadata !12, metadata !6)
  %src_bitcast = bitcast %struct.FOO* %3 to i32*
  %src_data = load i32, i32* %src_bitcast, noalias_sidechannel i32* undef, align 4, !noalias !6

On platforms with 32-bit pointers, pointers might be treated as 32-bit integers, hence the bitcast. I attach an llvm-lit test case, hope it helps. F11327642: noalias-copyguard.ll <https://reviews.llvm.org/F11327642>

I don't think that we can emit an `llvm.noalias` intrinsic here since the pointer is treated as a integer, so maybe we should just bail.. What do you think?


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

https://reviews.llvm.org/D68515