Support reg_addr register class in s390x inline assembly by taiki-e · Pull Request #119431 · rust-lang/rust

taiki-e · 2023-12-30T07:19:03Z

In s390x, r0 cannot be used as an address register (it is evaluated as zero in an address context).

Therefore, currently, in assemblies involving memory accesses, r0 must be marked as clobbered or explicitly used to a non-address or explicitly use an address register to prevent r0 from being allocated to a register for the address.

This patch adds a register class for allocating general-purpose registers, except r0, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.)

This is identical to the a constraint in LLVM and GCC:

https://llvm.org/docs/LangRef.html#supported-constraint-code-list

a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero).

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html

a
Address register (general purpose register except r0)

cc @uweigand

r? @Amanieu

@rustbot label +O-SystemZ +A-inline-assembly

rustbot · 2023-12-30T07:19:12Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Amanieu · 2024-01-02T19:27:51Z

src/doc/unstable-book/src/language-features/asm-experimental-arch.md

 | PowerPC      | `reg_nonzero`  | None     | `3`            | `b`           |
 | PowerPC      | `freg`         | None     | `0`            | None          |
 | s390x        | `reg`          | None     | `%r0`          | None          |
+| s390x        | `reg_addr`     | None     | `%r1`          | `a`           |


a is a constraint, not a modifier. Modifiers only affect how a register is formatted to a string. This should just be None.

Oh, I included it because the PowerPC's b constraint (reg_nonzero) is there, but they are indeed wrong.
Fixed them.

Amanieu · 2024-01-03T10:16:32Z

@bors r+

bors · 2024-01-03T10:16:35Z

📌 Commit ee41651 has been approved by Amanieu

It is now in the queue for this repository.

bors · 2024-01-03T10:16:36Z

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

Support reg_addr register class in s390x inline assembly In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context). Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L58) or [explicitly used to a non-address](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L135) or explicitly use an address register to prevent `r0` from being allocated to a register for the address. This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.) This is identical to the `a` constraint in LLVM and GCC: https://llvm.org/docs/LangRef.html#supported-constraint-code-list > a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero). https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html > a > Address register (general purpose register except r0) cc `@uweigand` r? `@Amanieu`

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#117636 (add test for rust-lang#117626) - rust-lang#118704 (Promote `riscv32{im|imafc}` targets to tier 2) - rust-lang#119184 (Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern`) - rust-lang#119325 (custom mir: make it clear what the return block is) - rust-lang#119391 (Use Result::flatten in catch_with_exit_code) - rust-lang#119431 (Support reg_addr register class in s390x inline assembly) - rust-lang#119475 (Remove libtest's dylib) - rust-lang#119532 (Make offset_of field parsing use metavariable which handles any spacing) - rust-lang#119553 (stop feed vis when cant access for trait item) - rust-lang#119556 (Reland optimized-compiler-builtins config) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#117636 (add test for rust-lang#117626) - rust-lang#118704 (Promote `riscv32{im|imafc}` targets to tier 2) - rust-lang#119184 (Switch from using `//~ERROR` annotations with `--error-format` to `error-pattern`) - rust-lang#119325 (custom mir: make it clear what the return block is) - rust-lang#119391 (Use Result::flatten in catch_with_exit_code) - rust-lang#119431 (Support reg_addr register class in s390x inline assembly) - rust-lang#119475 (Remove libtest's dylib) - rust-lang#119532 (Make offset_of field parsing use metavariable which handles any spacing) - rust-lang#119553 (stop feed vis when cant access for trait item) - rust-lang#119574 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#119431 - taiki-e:asm-s390x-reg-addr, r=Amanieu Support reg_addr register class in s390x inline assembly In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context). Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L58) or [explicitly used to a non-address](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L135) or explicitly use an address register to prevent `r0` from being allocated to a register for the address. This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.) This is identical to the `a` constraint in LLVM and GCC: https://llvm.org/docs/LangRef.html#supported-constraint-code-list > a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero). https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html > a > Address register (general purpose register except r0) cc ``@uweigand`` r? ``@Amanieu``

Refs: rust-lang/rust#119431

uweigand · 2024-01-08T13:02:13Z

This patch adds a register class for allocating general-purpose registers, except r0, to make it easier to use address registers.

Thanks for taking care of this, @taiki-e !

Support reg_addr register class in s390x inline assembly In s390x, `r0` cannot be used as an address register (it is evaluated as zero in an address context). Therefore, currently, in assemblies involving memory accesses, `r0` must be [marked as clobbered](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L58) or [explicitly used to a non-address](https://github.com/taiki-e/atomic-maybe-uninit/blob/1a1155653a26667396c805954ab61c8cbb14de8c/src/arch/s390x.rs#L135) or explicitly use an address register to prevent `r0` from being allocated to a register for the address. This patch adds a register class for allocating general-purpose registers, except `r0`, to make it easier to use address registers. (powerpc already has a register class (reg_nonzero) for a similar purpose.) This is identical to the `a` constraint in LLVM and GCC: https://llvm.org/docs/LangRef.html#supported-constraint-code-list > a: A 32, 64, or 128-bit integer address register (excludes R0, which in an address context evaluates as zero). https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html > a > Address register (general purpose register except r0) cc ``@uweigand`` r? ``@Amanieu``

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (rust-lang#111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved rust-lang#130630 (comment) - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved rust-lang#130630 (comment) - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (rust-lang#119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (rust-lang/rustc_codegen_gcc#485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in rust-lang#127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... rust-lang#88245 (comment) cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ

Rollup merge of rust-lang#130630 - taiki-e:s390x-clobber-abi, r=Amanieu Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (rust-lang#111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved rust-lang#130630 (comment) - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved rust-lang#130630 (comment) - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (rust-lang#119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (rust-lang/rustc_codegen_gcc#485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in rust-lang#127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... rust-lang#88245 (comment) cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (rust-lang/rust#111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved rust-lang/rust#130630 (comment) - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved rust-lang/rust#130630 (comment) - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (rust-lang/rust#119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (#485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in rust-lang/rust#127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... rust-lang/rust#88245 (comment) cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#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 rust-lang#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. (rust-lang#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 rust-lang#111331. --- cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ +A-inline-assembly

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#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 rust-lang#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. (rust-lang#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 rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

Rollup merge of rust-lang#131258 - taiki-e:s390x-stabilize-asm, r=Amanieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#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 rust-lang#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. (rust-lang#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 rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang/rust#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang/rust#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 rust-lang/rust#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. (rust-lang/rust#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 rust-lang/rust#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#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 rust-lang#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. (rust-lang#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 rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

rustbot assigned Amanieu Dec 30, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 30, 2023

Amanieu reviewed Jan 2, 2024

View reviewed changes

Support reg_addr register class in s390x inline assembly

ee41651

taiki-e force-pushed the asm-s390x-reg-addr branch from 676c619 to ee41651 Compare January 3, 2024 09:03

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 3, 2024

matthiaskrgr mentioned this pull request Jan 4, 2024

Rollup of 10 pull requests #119570

Closed

matthiaskrgr mentioned this pull request Jan 4, 2024

Rollup of 10 pull requests #119578

Merged

bors merged commit 12c102e into rust-lang:master Jan 4, 2024

rustbot added this to the 1.77.0 milestone Jan 4, 2024

taiki-e deleted the asm-s390x-reg-addr branch January 5, 2024 05:12

taiki-e added a commit to taiki-e/atomic-maybe-uninit that referenced this pull request Jan 6, 2024

s390x: Use reg_addr register class

9ee7f57

Refs: rust-lang/rust#119431

rustbot added the O-SystemZ Target: SystemZ processors (s390x) label Sep 20, 2024

taiki-e mentioned this pull request Sep 20, 2024

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

Merged

taiki-e mentioned this pull request Oct 4, 2024

Stabilize s390x inline assembly #131258

Merged

rustbot added the A-inline-assembly Area: Inline assembly (`asm!(…)`) label Oct 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support reg_addr register class in s390x inline assembly#119431

Support reg_addr register class in s390x inline assembly#119431
bors merged 1 commit intorust-lang:masterfrom
taiki-e:asm-s390x-reg-addr

taiki-e commented Dec 30, 2023 •

edited

Loading

Uh oh!

rustbot commented Dec 30, 2023

Uh oh!

Amanieu Jan 2, 2024

Uh oh!

taiki-e Jan 3, 2024

Uh oh!

Amanieu commented Jan 3, 2024

Uh oh!

bors commented Jan 3, 2024

Uh oh!

bors commented Jan 3, 2024

Uh oh!

uweigand commented Jan 8, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

taiki-e commented Dec 30, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 30, 2023

Uh oh!

Amanieu Jan 2, 2024

Choose a reason for hiding this comment

Uh oh!

taiki-e Jan 3, 2024

Choose a reason for hiding this comment

Uh oh!

Amanieu commented Jan 3, 2024

Uh oh!

bors commented Jan 3, 2024

Uh oh!

bors commented Jan 3, 2024

Uh oh!

uweigand commented Jan 8, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

taiki-e commented Dec 30, 2023 •

edited

Loading