[AArch64] Overlapping registers allocated to input and lateout constraints

[nikic]

https://llvm.godbolt.org/z/xz6PYTaW3

target triple = "aarch64-unknown-linux-gnu"

define i1 @test(ptr %ptr) "target-features"="+lse" {
  %2 = call { i64, i64 } asm sideeffect "casp x2, x3, x2, x3, [${2}]", "=&{x2},=&{x3},r,0,1,~{memory}"(ptr %ptr, i64 0, i64 0)
  %3 = call i32 asm sideeffect "2:\0Aldxp xzr, ${0}, [${1}]\0Astxp ${0:w}, ${2}, ${3}, [${1}]\0Acbnz ${0:w}, 2b\0A", "=&r,r,r,r,~{memory}"(ptr %ptr, i64 0, i64 0)
  %4 = call i32 asm sideeffect "2:\0Aldxp xzr, ${0}, [${1}]\0Astxp ${0:w}, ${2}, ${3}, [${1}]\0Acbnz ${0:w}, 2b\0A", "=&r,r,r,r,~{memory}"(ptr %ptr, i64 undef, i64 0)
  ret i1 false
}

Results in:

<inline asm>:3:6: error: unpredictable STXP instruction, status is also a source
stxp w8, x8, x10, [x0]

Note that ${0:w} and ${2} are allocated to overlapping registers, even though a lateout =& constraint is used.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Nikita Popov (nikic)

https://llvm.godbolt.org/z/xz6PYTaW3 ```llvm target triple = "aarch64-unknown-linux-gnu"

define i1 @test(ptr %ptr) "target-features"="+lse" {
%2 = call { i64, i64 } asm sideeffect "casp x2, x3, x2, x3, [${2}]", "=&{x2},=&{x3},r,0,1,{memory}"(ptr %ptr, i64 0, i64 0)
%3 = call i32 asm sideeffect "2:\0Aldxp xzr, ${0}, [${1}]\0Astxp ${0:w}, ${2}, ${3}, [${1}]\0Acbnz ${0:w}, 2b\0A", "=&r,r,r,r,{memory}"(ptr %ptr, i64 0, i64 0)
%4 = call i32 asm sideeffect "2:\0Aldxp xzr, ${0}, [${1}]\0Astxp ${0:w}, ${2}, ${3}, [${1}]\0Acbnz ${0:w}, 2b\0A", "=&r,r,r,r,~{memory}"(ptr %ptr, i64 undef, i64 0)
ret i1 false
}

Results in:

<inline asm>:3:6: error: unpredictable STXP instruction, status is also a source
stxp w8, x8, x10, [x0]

Note that `${0:w}` and `${2}` are allocated to overlapping registers, even though a lateout `=&` constraint is used.
</details>

[nikic]

The fact that one is a subreg doesn't seem to be relevant (same behavior if using i64 result and dropping the :ws).

The fact that the operand is undef does seem relevant, but I'm not sure if it just perturbs allocation.

Maybe there is an (incorrect) assumption that clobbering does not matter for undef operands?

[davemgreen]

This sounds like it might be similar to the issue #77770 was addressing, IIRC. I don't know much more about it than that though (like why the register allocator is doing it or why it isn't better to fix as part of the register allocator).

[nikic]

Maybe @qcolombet has some insight into the regalloc behavior here.

[qcolombet]

The fact that the operand is undef does seem relevant, but I'm not sure if it just perturbs allocation.

It perturbs the allocation because it says that we do not care about the content of the register. Hence, we end up with an empty live-range which doesn't interfere with anything else and we end up reusing something that is already used. This is normally fine, but breaks the verifier here.

Technically I would say you get what you asked for: undef stored value ==> undef behavior for STXP.
I'm playing devil's advocate here to be fair.

I don't see an easy fix in the allocator though.

[nikic]

The fact that the operand is undef does seem relevant, but I'm not sure if it just perturbs allocation.

It perturbs the allocation because it says that we do not care about the content of the register. Hence, we end up with an empty live-range which doesn't interfere with anything else and we end up reusing something that is already used. This is normally fine, but breaks the verifier here.

Technically I would say you get what you asked for: undef stored value ==> undef behavior for STXP. I'm playing devil's advocate here to be fair.

I don't think this interpretation is quite right in this case, because an undef operand here should behave as-if it were any arbitrary value, while STXP with two equal registers is "constrained unpredictable" in a way that extends beyond that. That is, it may exhibit behavior that would not be observable for any specific choice of the undef value.

Independently of the STXP case, my expectation would also be that an inline asm block can only observe a single value for an input register, even if it has an undef value. Though given IR undef semantics, I can see how a reasonable person might disagree with that expectation...

[efriedma-quic]

I agree the current behavior is wrong; ensuring no overlap should be more intuitive for people writing inline asm. (Granted, I doubt this has much practical effect either way... if you end up with an inline asm with an undef input, you're probably doing something wrong.)

This is essentially the same as #77770.

[nikic]

It seems like making InitUndef work on AArch64 is the right way forward here. I've put up #106744 to make it easier to extend the pass to additional targets.

[nikic]

#108353 enables the pass for all targets and this does fix the equivalent issue when using intrinsics. Just enabling the pass doesn't help the inline asm case though, so something more is missing...

[nikic]

The missing bit turned out to be that the pass iterates over defs() instead of all_defs(). I'll fix that after the main change lands.