LLVM memcpy/set optimizations prevented by uninitialized padding

[MacDue]

Reduced from a C++ class initialization. It should be possible to rewrite:

define void @src(ptr %a) {
  %alloca = alloca <{ [2 x i8], i64, i64, i64 }>, align 2
  %3 = getelementptr inbounds nuw i8, ptr %alloca, i64 2
  call void @llvm.memset.p0.i64(ptr noundef nonnull align 2 dereferenceable(24) %3, i8 0, i64 24, i1 false)
  call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 2 dereferenceable(26) %a, ptr noundef nonnull align 2 dereferenceable(26) %alloca, i64 26, i1 false)
  ret void
}

Into something like:

define void @tgt(ptr %a) {
  %3 = getelementptr inbounds nuw i8, ptr %a, i64 2
  call void @llvm.memset.p0.i64(ptr noundef nonnull align 2 dereferenceable(24) %3, i8 0, i64 24, i1 false)
  ret void
}

Which eliminates an alloca and a copy, but LLVM current fails to do so: https://godbolt.org/z/hKqnzs7v7

Proof: https://alive2.llvm.org/ce/z/2rqejL

[antoniofrighetto]

Agree the transformation should be fine as long as the uninitialized memory is kept untouched (https://alive2.llvm.org/ce/z/bmTUDK). I'll take a look at this soon. Out of personal curiosity, would it be possible to share the original C++ snippet the IR comes from?

[MacDue]

A simple example of C++ with an issue like this is: https://godbolt.org/z/5T3nY7vW4

It should be possible to combine the memcpy into a memset (https://alive2.llvm.org/ce/z/b992LY), which would produce much better code (https://godbolt.org/z/jnYY8zYTs).