Clobber between alloca and stack arg

[nikic]

define i1 @test(ptr %a0, ptr %a1, ptr %a2, ptr %a3, ptr %a4, ptr %a5, i128 %x) {
  %alloca = alloca i128
  store i128 %x, ptr %alloca
  store i128 0, ptr %alloca
  %cmp = icmp eq i128 %x, -1
  ret i1 %cmp
}

Results in:

	movq	8(%rsp), %rax
	xorps	%xmm0, %xmm0
	movaps	%xmm0, 8(%rsp)
	andq	16(%rsp), %rax
	cmpq	$-1, %rax
	sete	%al
	retq

The final argument is passed in 8(%rsp) and 16(%rsp). The zero store writes 128 bits to 8(%rsp), clobbering the argument before it is read.

[llvmbot]

@llvm/issue-subscribers-backend-x86

[nikic]

This should be a bug in the findArgumentCopyElisionCandidates() optimization.

[nikic]

This is another of those issues where I wonder how we never hit this before. The copy elision optimization seems to completely fail to account for the possibility that a stack slot that an argument has been stored into can be clobbered with a different value later.

[nikic]

Okay, this is less bad than I thought. Apparently the way this is supposed to work is that if such a store gets elided, the load chain becomes the new root, ensuring that these loads happen before any potential clobbers. However, it seems that the code assumes that the argument only has one part, and will only preserve the chain of that first part. So in this case we lose the chain from the second load.

[nikic]

Candidate patch: https://reviews.llvm.org/D153432