-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for asm_experimental_arch #93335
Comments
Is there any chance that wasm32 assembly support will be stabilized any time soon? Are there any tasks where contributions might speed this up? |
This is needed to use `probe!` on ppc64le and s390x See rust-lang/rust#93335 Also loosen version requirement on `probe`; on Fedora we have been building with `probe` 0.5.1 with no issue. Tested by doing a scratch build on Fedora's Koji build system: https://koji.fedoraproject.org/koji/taskinfo?taskID=123358009 Signed-off-by: Michel Lind <[email protected]>
These require `feature(asm_experimental_arch)` which only works on nightly compilers. See rust-lang/rust#93335 Also loosen version requirement on `probe`; on Fedora we have been building with `probe` 0.5.1 with no issue. Tested by doing a scratch build on Fedora's Koji build system: https://koji.fedoraproject.org/koji/taskinfo?taskID=123361398 Signed-off-by: Michel Lind <[email protected]>
Is there any news about AVR ? If not, where and how can I contribute to this? |
The top post mentions the following:
Anyone can post a stabilization (or status) report answering the above, probably with examples/tests, and that would be a good place for any platform to start. It would also be good to make sure there aren't any open LLVM issues, and mention it there. The bar for enabling AVR should be pretty low since it is tier 3. I am not a decision maker here but I think any of the tier 3 targets could probably be stabilized with just the report and some real-world usage backing it up. I'm not sure what exactly would be needed for the tier 2 and above targets, e.g. WASM as requested by @solomatov. Having a better picture of LLVM support is more important. @alexcrichton maybe you have an idea about the WASM picture here, or know who would? |
Cc @ecnelises with the above in case you are interested in moving ppc assembly forward, based on linked issues it seems like there may be some ecosystem use cases. |
Ah I don't know very much about inline assembly for the wasm target. I believe it works enough to do "some things" but that's the extent of my knowledge, and I wouldn't be prepared to assist with or myself propose stabilization. I also don't know who might know more about the wasm side of things other than "generally LLVM folks doing wasm things may know more", which I realize is unfortunately not very specific or actionable... |
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
@AtomicGamer9523 #131258 is an example of stabilizing assembly for a target that is behind this feature. You could probably put up a similar PR for AVR. |
In my understanding, here is the status on each architecture other than s390x (which already has stabilization PR):
FYI:
|
This commit adds the relevant registers to the list of clobbered regis- ters (part of rust-lang#93335). This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are > registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them > without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call- > clobbered, but this knowledge is not exposed explicitly to the > compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. An open question is the T-flag in the SREG. This is a one-bit temporary storage inside a special-purpose register, which therefore cannot simply be added to the clobber ABI list. Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
This commit adds the relevant registers to the list of clobbered regis- ters (part of rust-lang#93335). This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are > registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them > without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call- > clobbered, but this knowledge is not exposed explicitly to the > compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways). Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
Support clobber_abi in MSP430 inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf) cc `@cr1901` r? `@Amanieu` `@rustbot` label +O-msp430
Support clobber_abi in MSP430 inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf) cc ``@cr1901`` r? ``@Amanieu`` ``@rustbot`` label +O-msp430
Rollup merge of rust-lang#131310 - taiki-e:msp430-clobber-abi, r=Amanieu Support clobber_abi in MSP430 inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf) cc ``@cr1901`` r? ``@Amanieu`` ``@rustbot`` label +O-msp430
This commit adds the relevant registers to the list of clobbered regis- ters (part of rust-lang#93335). This follows the [ABI documentation] of AVR-GCC: > The [...] call-clobbered general purpose registers (GPRs) are > registers that might be destroyed (clobbered) by a function call. > > - **R18–R27, R30, R31** > > These GPRs are call clobbered. An ordinary function may use them > without restoring the contents. [...] > > - **R0, T-Flag** > > The temporary register and the T-flag in SREG are also call- > clobbered, but this knowledge is not exposed explicitly to the > compiler (R0 is a fixed register). Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM. Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways). Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways. [ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers
…rkingjubilee Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This basically does a similar thing I did in rust-lang#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces rust-lang#111335 and rust-lang#124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
…ingjubilee Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This basically does a similar thing I did in rust-lang#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces rust-lang#111335 and rust-lang#124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
Basic inline assembly support for SPARC and SPARC64 This implements asm_experimental_arch (tracking issue rust-lang#93335) for SPARC and SPARC64. This PR includes: - General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`) Supported types: i8, i16, i32, i64 (SPARC64-only) Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`) - `y` register (clobber-only, needed for clobber_abi) - preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`) The following are *not* included: - 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?) - Floating-point registers (LLVM/GCC constraint `e`/`f`): I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description. - clobber_abi: Support for floating-point registers is needed. Refs: - LLVM - Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52 - Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td - Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list - GCC - Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658 - Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html - SPARC ISA/ABI - (64-bit ISA) The SPARC Architecture Manual, Version 9 (32-bit ISA) The SPARC Architecture Manual, Version 8 (64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35 (32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition The above docs can be downloaded from https://sparc.org/technical-documents - (32-bit V8+ ABI) The V8+ Technical Specification https://temlib.org/pub/SparcStation/Standards/V8plus.pdf cc `@thejpster` (sparc-unknown-none-elf target maintainer) (AFAIK, other sparc/sprac64 targets don't have target maintainers) r? `@Amanieu` `@rustbot` label +O-SPARC +A-inline-assembly
Basic inline assembly support for SPARC and SPARC64 This implements asm_experimental_arch (tracking issue rust-lang/rust#93335) for SPARC and SPARC64. This PR includes: - General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`) Supported types: i8, i16, i32, i64 (SPARC64-only) Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`) - `y` register (clobber-only, needed for clobber_abi) - preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`) The following are *not* included: - 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?) - Floating-point registers (LLVM/GCC constraint `e`/`f`): I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description. - clobber_abi: Support for floating-point registers is needed. Refs: - LLVM - Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52 - Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td - Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list - GCC - Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658 - Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html - SPARC ISA/ABI - (64-bit ISA) The SPARC Architecture Manual, Version 9 (32-bit ISA) The SPARC Architecture Manual, Version 8 (64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35 (32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition The above docs can be downloaded from https://sparc.org/technical-documents - (32-bit V8+ ABI) The V8+ Technical Specification https://temlib.org/pub/SparcStation/Standards/V8plus.pdf cc `@thejpster` (sparc-unknown-none-elf target maintainer) (AFAIK, other sparc/sprac64 targets don't have target maintainers) r? `@Amanieu` `@rustbot` label +O-SPARC +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
…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
…manieu,traviscross Stabilize Arm64EC inline assembly This stabilizes inline assembly for Arm64EC ("Emulation Compatible"). Corresponding reference PR: rust-lang/reference#1653 --- 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#131332. > - It must be possible to clobber every register that is normally clobbered by a function call. This is possible from the time of the initial implementation. > - Generally review that the exposed register classes make sense. The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable. The following registers cannot be used in Arm64EC compared to AArch64: - `x13`, `x14`, `x23`, `x24`, `x28` (register class: `reg`) - `v[16-31]` (register class: `vreg`) - `p[0-15]`, `ffr` (clobber-only register class `preg`) These are disallowed by the ABI (see also [abi docs](https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170#register-mapping) for `reg`/`vreg` and rust-lang#131332 (comment) for `preg`). Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64. --- cc `@dpaoliello` r? `@Amanieu` `@rustbot` label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp
Rollup merge of rust-lang#131781 - taiki-e:arm64ec-stabilize-asm, r=Amanieu,traviscross Stabilize Arm64EC inline assembly This stabilizes inline assembly for Arm64EC ("Emulation Compatible"). Corresponding reference PR: rust-lang/reference#1653 --- 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#131332. > - It must be possible to clobber every register that is normally clobbered by a function call. This is possible from the time of the initial implementation. > - Generally review that the exposed register classes make sense. The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable. The following registers cannot be used in Arm64EC compared to AArch64: - `x13`, `x14`, `x23`, `x24`, `x28` (register class: `reg`) - `v[16-31]` (register class: `vreg`) - `p[0-15]`, `ffr` (clobber-only register class `preg`) These are disallowed by the ABI (see also [abi docs](https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170#register-mapping) for `reg`/`vreg` and rust-lang#131332 (comment) for `preg`). Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64. --- cc `@dpaoliello` r? `@Amanieu` `@rustbot` label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp
…manieu,traviscross Stabilize Arm64EC inline assembly This stabilizes inline assembly for Arm64EC ("Emulation Compatible"). Corresponding reference PR: rust-lang/reference#1653 --- 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#131332. > - It must be possible to clobber every register that is normally clobbered by a function call. This is possible from the time of the initial implementation. > - Generally review that the exposed register classes make sense. The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable. The following registers cannot be used in Arm64EC compared to AArch64: - `x13`, `x14`, `x23`, `x24`, `x28` (register class: `reg`) - `v[16-31]` (register class: `vreg`) - `p[0-15]`, `ffr` (clobber-only register class `preg`) These are disallowed by the ABI (see also [abi docs](https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170#register-mapping) for `reg`/`vreg` and rust-lang#131332 (comment) for `preg`). Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64. --- cc `@dpaoliello` r? `@Amanieu` `@rustbot` label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp
Basic inline assembly support for SPARC and SPARC64 This implements asm_experimental_arch (tracking issue rust-lang#93335) for SPARC and SPARC64. This PR includes: - General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`) Supported types: i8, i16, i32, i64 (SPARC64-only) Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`) - `y` register (clobber-only, needed for clobber_abi) - preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`) The following are *not* included: - 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?) - Floating-point registers (LLVM/GCC constraint `e`/`f`): I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description. - clobber_abi: Support for floating-point registers is needed. Refs: - LLVM - Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52 - Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td - Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list - GCC - Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658 - Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html - SPARC ISA/ABI - (64-bit ISA) The SPARC Architecture Manual, Version 9 (32-bit ISA) The SPARC Architecture Manual, Version 8 (64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35 (32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition The above docs can be downloaded from https://sparc.org/technical-documents - (32-bit V8+ ABI) The V8+ Technical Specification https://temlib.org/pub/SparcStation/Standards/V8plus.pdf cc `@thejpster` (sparc-unknown-none-elf target maintainer) (AFAIK, other sparc/sprac64 targets don't have target maintainers) r? `@Amanieu` `@rustbot` label +O-SPARC +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
The feature gate for the issue is
#![feature(asm_experimental_arch)]
.Summary
This feature tracks
asm!
andglobal_asm!
support for the following architectures:Status
Each architecture needs to be reviewed before stabilization:
clobber_abi
.The text was updated successfully, but these errors were encountered: