miscompilation with -fstrict-vtable-pointers

[sylvain-audi]

I noticed invalid code generation using -fstrict-vtable-pointers on clang 18.1.0.

Here is a repro: https://godbolt.org/z/h9bx14bWG

Notice the @llvm.memcpy.p0.p0.i64 call with an undef parameter, it seems to be the cause of the runtime crash.

Notes:

• Bisecting on llvm passes (argument -mllvm -opt-bisect-limit=), I found that the issue appears with an SROA pass.
• The generated code was valid with clang 17.0.1. By bisecting on git, the invalid generation started with the commit from this PR: [SROA] Allow llvm.launder.invariant.group intrinsic to be splittable #72056

@antoniofrighetto @nikic could you identify whether this is an SROA bug?

[nikic]

Yes, this is a SROA bug. Reduced: https://llvm.godbolt.org/z/b7ha4K6Gf

define void @test(ptr %ptr) {
  %alloca = alloca { i64, i64 }, align 8
  %launder = call ptr @llvm.launder.invariant.group.p0(ptr %alloca)
  call void @llvm.memcpy.p0.p0.i64(ptr %launder, ptr %ptr, i64 16, i1 false)
  ret void
}

[antoniofrighetto]

I noticed invalid code generation using -fstrict-vtable-pointers on clang 18.1.0.

Thanks for reporting, I'm taking a look.

[antoniofrighetto]

Yes, this is a SROA bug. Reduced: https://llvm.godbolt.org/z/b7ha4K6Gf

define void @test(ptr %ptr) {
  %alloca = alloca { i64, i64 }, align 8
  %launder = call ptr @llvm.launder.invariant.group.p0(ptr %alloca)
  call void @llvm.memcpy.p0.p0.i64(ptr %launder, ptr %ptr, i64 16, i1 false)
  ret void
}

I think this should suffice to demonstrate that the stack-allocated memory should not be promoted to register when the pointer to such a memory region is laundered.