[llvm] [SROA] Allow rewriting memcpy depending on tbaa.struct (PR #77597)

[Björn Pettersson via llvm-commits]

bjope wrote:

Haven't had much luck in finding a different solution.

Looking at findCommonType it currently ignore all intrinsics. But given that we want to detect if there is a memcpy writing to the alloca (or at least a slice) we would need to also consider MemTransferIntrinsics.

My use case kind of looks like this:
```
  %struct_i40x2 = type { i40, i40 }
  ...
  %sum = alloca %struct_i40x2
  %tmp = alloca %struct_i40x2
  %hi = getelementptr inbounds %struct_i40x2, ptr %sum, i32 0, i32 0
  store i40 0, ptr %hi, align 1, !tbaa !17
  %lo = getelementptr inbounds %struct_i40x2, ptr %sum, i32 0, i32 1
  store i40 0, ptr %lo, align 1, !tbaa !22
  ...
for.body:
  ...
  call void @llvm.memcpy.p0.p0.i32(ptr align 1 %tmp, ptr align 1 %sum, i32 12, i1 false), !tbaa.struct !37
  %7 = load %struct_i40x2, ptr %tmp
  %8 = extractvalue %struct_i40x2 %7, 0
  %9 = extractvalue %struct_i40x2 %7, 1
  %10 = call %struct_i40x2 @llvm.accumulate(i40 %8, i40 %9)
  store %struct_i40x2 %10, ptr %sum
```

So I guess that when splitting %tmp one would need to know that data copied from %sum is a pure i40 and not an i40 type that might alias with something with different bit padding. Thus one would need to analyze %sum first to find a common type for the slices. Since %sum is being written to using the result from the intrinsic call, one need to be able to rely on that the intrinsic is operating on the exact type (seeing the struct as two i40). But we can't do that in general, if the frontend just has picked one "random" type in case the struct contains unions?!?!

One could perhaps do something similar to getTypePartition. To look at the IR type to find a subtype. But that would require that we make sure both clang/LLVM (and other frontends) adhere to the rule of picking a type that is covering all bits when having unions.

Not quite sure what to do if the proposal using tbaa.struct is rejected.
(I'll probably use that solution downstream as a quick workaround unless there is some obvious fault making it invalid.)

https://github.com/llvm/llvm-project/pull/77597