Skip to content
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

Open
Amanieu opened this issue Jan 26, 2022 · 7 comments
Open

Tracking Issue for asm_experimental_arch #93335

Amanieu opened this issue Jan 26, 2022 · 7 comments
Labels
A-inline-assembly Area: Inline assembly (`asm!(…)`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-asm `#![feature(asm)]` (not `llvm_asm`)

Comments

@Amanieu
Copy link
Member

Amanieu commented Jan 26, 2022

The feature gate for the issue is #![feature(asm_experimental_arch)].

Summary

This feature tracks asm! and global_asm! support for the following architectures:

Status

Each architecture needs to be reviewed before stabilization:

  • It must have clobber_abi.
  • It must be possible to clobber every register that is normally clobbered by a function call.
  • Generally review that the exposed register classes make sense.
@Amanieu Amanieu added A-inline-assembly Area: Inline assembly (`asm!(…)`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-asm `#![feature(asm)]` (not `llvm_asm`) labels Jan 26, 2022
@solomatov
Copy link

Is there any chance that wasm32 assembly support will be stabilized any time soon? Are there any tasks where contributions might speed this up?

michel-slm added a commit to michel-slm/libbpf-rs that referenced this issue Sep 13, 2024
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]>
michel-slm added a commit to michel-slm/libbpf-rs that referenced this issue Sep 13, 2024
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]>
@AtomicGamer9523
Copy link

Is there any news about AVR ? If not, where and how can I contribute to this?

@tgross35
Copy link
Contributor

tgross35 commented Sep 27, 2024

The top post mentions the following:

Each architecture needs to be reviewed before stabilization:
* It must have clobber_abi.
* It must be possible to clobber every register that is normally clobbered by a function call.
* Generally review that the exposed register classes make sense.

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?

@tgross35
Copy link
Contributor

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.

@alexcrichton
Copy link
Member

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...

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Oct 1, 2024
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
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 1, 2024
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
@tgross35
Copy link
Contributor

tgross35 commented Oct 5, 2024

@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.

@taiki-e
Copy link
Member

taiki-e commented Oct 5, 2024

In my understanding, here is the status on each architecture other than s390x (which already has stabilization PR):
(Disclaimer: I'm not an expert of any of these. In particular, I know almost nothing about asm for WASM, GPUs, and BPF.)


FYI:

jfrimmel added a commit to jfrimmel/rust that referenced this issue Oct 6, 2024
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
jfrimmel added a commit to jfrimmel/rust that referenced this issue Oct 6, 2024
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
tgross35 added a commit to tgross35/rust that referenced this issue Oct 11, 2024
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
tgross35 added a commit to tgross35/rust that referenced this issue Oct 12, 2024
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
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 12, 2024
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
jfrimmel added a commit to jfrimmel/rust that referenced this issue Oct 14, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inline-assembly Area: Inline assembly (`asm!(…)`) B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-asm `#![feature(asm)]` (not `llvm_asm`)
Projects
None yet
Development

No branches or pull requests

6 participants