Jubilee 2f98dcf9ba
Rollup merge of #131258 - taiki-e:s390x-stabilize-asm, r=Amanieu
Stabilize s390x inline assembly

This stabilizes inline assembly for s390x (SystemZ).

Corresponding reference PR: https://github.com/rust-lang/reference/pull/1643

---

From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335

> Each architecture needs to be reviewed before stabilization:

> - It must have clobber_abi.

Done in https://github.com/rust-lang/rust/pull/130630.

> - It must be possible to clobber every register that is normally clobbered by a function call.

Done in the PR that added support for clobber_abi.

> - Generally review that the exposed register classes make sense.

The followings can be used as input/output:

- `reg` (`r[0-10]`, `r[12-14]`): General-purpose register

- `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context

  This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See https://github.com/rust-lang/rust/pull/119431 for details.

- `freg` (`f[0-15]`): Floating-point register

The followings are clobber-only:

- `vreg` (`v[0-31]`): Vector register

  Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (https://github.com/rust-lang/rust/issues/130869 tracks unstable stuff here)

- `areg` (`a[2-15]`): Access register

All of the above register classes except `reg_addr` are needed for `clobber_abi`.

The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM):

- `r11`: frame pointer
- `r15`: stack pointer
- `a0`, `a1`: Reserved for system use
- `c[0-15]` (control register)  Reserved by the kernel

Although not listed in the above requirements, `preserves_flags` is implemented in https://github.com/rust-lang/rust/pull/111331.

---

cc ``@uweigand``

r? ``@Amanieu``

``@rustbot`` label +O-SystemZ +A-inline-assembly
2024-11-09 20:28:43 -08:00
..
2024-11-08 10:46:00 +09:00
2024-10-22 12:55:16 +00:00
2024-10-06 18:12:25 +02:00
2024-11-02 05:33:56 +00:00
2024-09-09 19:39:43 -07:00
2024-09-09 19:39:43 -07:00
2024-08-29 18:12:31 +08:00
2024-09-09 19:39:43 -07:00
2024-06-16 17:19:25 +08:00
2024-07-14 13:48:29 +03:00
2024-07-14 13:48:29 +03:00
2024-07-14 13:48:29 +03:00
2024-10-22 02:25:38 -07:00
2024-08-07 00:41:48 -04:00
2024-06-19 21:26:48 +01:00
2024-09-09 19:39:43 -07:00

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb