[llvm] [AArch64] Reject non-scalable types in named Z-register constraints (PR #217551)

Jack Styles via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 20 02:18:46 PDT 2026


https://github.com/Stylie777 commented:

Thanks for the PR

Firstly, in the PR description can you please relate this PR to the original issue. See https://llvm.org/docs/BugLifeCycle.html#resolving-closing-bugs

Codex identified some issues where incorrect CodeGen can be generated here. Take the following IR
```
 define <vscale x 32 x i8> @f() {
    %v = call <vscale x 32 x i8>
        asm sideeffect "dup $0.b, #0", "={z0}"()
    ret <vscale x 32 x i8> %v
  }
```
`<vscale x 32 x i8>` is 256 × vscale bits, whereas one Z register is 128 × vscale bits, so the value requires two Z registers. The PR build nevertheless emits only:
```
  mov z0.b, #0
  ret
```
This leaves the z1 half of the return value undefined. Because {z0} explicitly names one register, I think this operand should be rejected.

It also looks like the following should also be rejected
```
  define <vscale x 32 x i1> @f() {
    %v = call <vscale x 32 x i1>
        asm sideeffect "dup $0.b, #0", "={z0}"()
    ret <vscale x 32 x i1> %v
  }
```
This has a similar issue where we would expect to see z0 and z1 defined as they are both used to construct p0 and p1, but only z0 is there so should be rejected.

I think here we need to verify that the legalisation assigns the operand to one Z register, then we know it's safe. Test cases for these should also be added to ensure we can reject them.


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


More information about the llvm-commits mailing list