| Age | Commit message (Collapse) | Author | Lines |
|---|
|
using minicore
|
|
Support input/output in vector registers of PowerPC inline assembly
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types as input/output.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| PowerPC | `vreg` | `altivec` | `i8x16`, `i16x8`, `i32x4`, `f32x4` |
| PowerPC | `vreg` | `vsx` | `f32`, `f64`, `i64x2`, `f64x2` |
In addition to floats and `core::simd` types listed above, `core::arch` types and custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types and relevant target features are currently unstable.
r? `@Amanieu`
`@rustbot` label +O-PowerPC +A-inline-assembly
|
|
|
|
|
|
Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18
Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/asm/aarch64.rs#L74-L76
However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs#L19
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs#L18
https://github.com/rust-lang/rust/blob/7db7489f9bc274cb60c4956bfa56de0185eb1b9b/compiler/rustc_codegen_llvm/src/llvm_util.rs#L764-L771
(As for ohos, +reserve-x18 is [redundant](https://github.com/llvm/llvm-project/commit/c417b7a695704d5bc3be23f34d1bfa505f5172de#diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c) since https://github.com/rust-lang/rust/commit/7a966b918870485e9b364e77f50c511f8c2cc275 that starting using llvm's ohos targets. So removed it from target-spec.)
This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.
r? `@Amanieu`
`@rustbot` label O-AArch64 +A-inline-assembly
|
|
Support predicate registers (clobber-only) in Hexagon inline assembly
The result of the Hexagon instructions such as comparison, store conditional, etc. is stored in predicate registers (`p[0-3]`), but currently there is no way to mark it as clobbered in `asm!`.
This is also needed for `clobber_abi` (although implementing `clobber_abi` will require the addition of support for [several more register classes](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.cpp#L71-L90). see also https://github.com/rust-lang/rust/issues/93335#issuecomment-2395210055).
Refs:
- [Section 6 "Conditional Execution" in Qualcomm Hexagon V73 Programmer’s Reference Manual](https://docs.qualcomm.com/bundle/publicresource/80-N2040-53_REV_AB_Qualcomm_Hexagon_V73_Programmers_Reference_Manual.pdf#page=90)
- [Register definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.td#L155)
cc `@androm3da` (target maintainer of hexagon-unknown-{[none-elf](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-none-elf.html#target-maintainers),[linux-musl](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-linux-musl.html#target-maintainers)})
r? `@Amanieu`
`@rustbot` label +A-inline-assembly
(Currently there is no O-hexagon label...)
|
|
Fix clobber_abi in RV32E and RV64E inline assembly
Currently clobber_abi in RV32E and RV64E inline assembly is implemented using InlineAsmClobberAbi::RiscV, but broken since x16-x31 cannot be used in RV32E and RV64E.
```
error: cannot use register `x16`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x17`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x28`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x29`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x30`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
error: cannot use register `x31`: register can't be used with the `e` target feature
--> <source>:42:14
|
42 | asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
| ^^^^^^^^^^^^^^^^
```
r? `@Amanieu`
`@rustbot` label O-riscv +A-inline-assembly
|
|
-Zfixed-x18
|
|
|
|
|
|
|
|
When labels are present, the `noreturn` option really means that asm block
won't fallthrough -- if labels are present, then outputs can still be
meaningfully used.
|
|
When outputs are used together with labels, they are considered
to be written for all destinations, not only when falling through.
|
|
|
|
|
|
|
|
assembly
|
|
|
