Commit Graph

119 Commits

Author SHA1 Message Date
bors
f981b2e27a Auto merge of #133659 - jieyouxu:rollup-576gh4p, r=jieyouxu
Rollup of 6 pull requests

Successful merges:

 - #131551 (Support input/output in vector registers of PowerPC inline assembly)
 - #132515 (Fix and undeprecate home_dir())
 - #132721 (CI: split x86_64-mingw job)
 - #133106 (changes old intrinsic declaration to new declaration)
 - #133496 (thread::available_parallelism for wasm32-wasip1-threads)
 - #133548 (Add `BTreeSet` entry APIs to match `HashSet`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-30 17:18:00 +00:00
许杰友 Jieyou Xu (Joe)
1aa01927d3 Rollup merge of #131551 - taiki-e:ppc-asm-vreg-inout, r=Amanieu
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
2024-11-30 12:57:32 +08:00
许杰友 Jieyou Xu (Joe)
ab4588a619 Rollup merge of #133587 - taiki-e:loongarch-asm-freg, r=Amanieu
Fix target_feature handling in freg of LoongArch inline assembly

In LoongArch inline assembly, freg currently always accepts f32/f64 as input/output.

9b4d7c6a40/compiler/rustc_target/src/asm/loongarch.rs (L41)

However, these types actually require f/d target features as in RISC-V.
Otherwise, an (ugly) compile error will occur: https://godbolt.org/z/K61Gq1E9E

f32/f64 without f:

```
error: couldn't allocate output register for constraint '{$f1}'
  --> <source>:12:11
   |
12 |     asm!("", in("$f1") x, lateout("$f1") y);
   |           ^
```

f64 with f but without d:

```
error: scalar-to-vector conversion failed, possible invalid constraint for vector type
  --> <source>:19:11
   |
19 |     asm!("", in("$f1") x, lateout("$f1") y);
   |           ^
```

cc ``@heiher``

r? ``@Amanieu``

``@rustbot`` label +O-LoongArch +A-inline-assembly
2024-11-30 12:56:53 +08:00
Taiki Endo
df8feb5067 Support floats in input/output in vector registers of PowerPC inline assembly 2024-11-29 03:10:07 +09:00
Taiki Endo
0c8e36bb30 Fix target_feature handling in freg of LoongArch inline assembly 2024-11-29 03:01:33 +09:00
Taiki Endo
0f8ebba54a Support #[repr(simd)] types in input/output of PowerPC inline assembly 2024-11-29 00:24:36 +09:00
Julian Frimmel
67d2f3f685 Reword error message of reserved AVR registers
Those are reserved as per the GCC (and thus LLVM) ABI, which is distinct from an
issue. The rewording was requested in this [review].

[review]: https://github.com/rust-lang/rust/pull/131323#issuecomment-2479178721
2024-11-28 16:12:04 +01:00
Julian Frimmel
ba73166556 Support clobber_abi for AVR inline assembly
This commit adds the relevant registers to the list of clobbered regis-
ters (part of #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
2024-11-28 16:12:02 +01:00
Guillaume Gomez
23bab15d73 Rollup merge of #133463 - taiki-e:aarch64-asm-x18, r=Amanieu
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.

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

7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs (L19)
7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs (L18)
7db7489f9b/compiler/rustc_codegen_llvm/src/llvm_util.rs (L764-L771)

(As for ohos, +reserve-x18 is [redundant](c417b7a695 (diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c)) since 7a966b9188 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
2024-11-28 12:06:02 +01:00
Guillaume Gomez
470c4f94e8 Rollup merge of #133452 - taiki-e:hexagon-asm-pred, r=Amanieu
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...)
2024-11-28 12:06:02 +01:00
Guillaume Gomez
89ae19ee0d Rollup merge of #133422 - taiki-e:riscv-e-clobber-abi, r=Amanieu
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
2024-11-28 12:06:01 +01:00
Taiki Endo
687dc19cb6 Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18 2024-11-26 03:10:22 +09:00
Taiki Endo
59f01cdbf4 Support predicate registers (clobber-only) in Hexagon inline assembly 2024-11-25 23:11:17 +09:00
Taiki Endo
736c397f41 Fix clobber_abi in RV32E and RV64E inline assembly 2024-11-25 00:36:22 +09:00
Taiki Endo
c024d8ccdf Make s390x non-clobber-only vector register support unstable 2024-11-24 21:42:22 +09:00
Taiki Endo
2c8f6de1ba Support input/output in vector registers of s390x inline assembly 2024-11-22 04:18:14 +09:00
bors
b91a3a0560 Auto merge of #132472 - taiki-e:sparc-asm, r=Amanieu
Basic inline assembly support for SPARC and SPARC64

This implements asm_experimental_arch (tracking issue https://github.com/rust-lang/rust/issues/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 63b6967b06/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
2024-11-07 21:07:06 +00:00
Taiki Endo
e2d50315ef Add links about clobber_abi on PowerPC 2024-11-07 22:21:27 +09:00
Taiki Endo
01b5a678c5 Remove fixme comment about clobber_abi on PowerPC 2024-11-07 22:13:15 +09:00
Taiki Endo
241f82ad91 Basic inline assembly support for SPARC and SPARC64 2024-11-07 21:19:03 +09:00
Taiki Endo
d19517dcd0 Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly 2024-11-02 20:26:08 +09:00
Matthias Krüger
dbb0581ff5 Rollup merge of #131667 - taiki-e:aarch64-inline-asm-reg-emit, r=Amanieu
Fix AArch64InlineAsmReg::emit

Currently, this method uses `self as u32 - Self::x0 as u32` to get register index:
36780360b6/compiler/rustc_target/src/asm/aarch64.rs (L204)

However, this is incorrect for reasons explained in the following comment:
36780360b6/compiler/rustc_codegen_llvm/src/asm.rs (L544-L549)

r? ``@Amanieu``

``@rustbot`` label O-AArch64 +A-inline-assembly
2024-10-14 17:06:38 +02:00
Taiki Endo
67ebb6c20b Fix AArch64InlineAsmReg::emit 2024-10-14 06:04:07 +09:00
Taiki Endo
d858dfedbb Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly 2024-10-14 05:30:45 +09:00
Taiki Endo
3743618c13 Support clobber_abi in MSP430 inline assembly 2024-10-06 08:14:44 +09:00
Guillaume Gomez
344b6a1668 Rollup merge of #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 #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 (https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- ~~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](33ccc1314d/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 https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- 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 (https://github.com/rust-lang/rust/pull/119431)...

Note:

- GCC seems to [recognize only `a0` and `a1`](33ccc1314d/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 (https://github.com/rust-lang/rustc_codegen_gcc/issues/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 https://github.com/rust-lang/rust/pull/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... https://github.com/rust-lang/rust/pull/88245#issuecomment-905559591

cc `@uweigand`

r? `@Amanieu`

`@rustbot` label +O-SystemZ
2024-10-01 17:32:07 +02:00
Michael Goulet
c682aa162b Reformat using the new identifier sorting from rustfmt 2024-09-22 19:11:29 -04:00
Taiki Endo
fa125e2be6 Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly 2024-09-21 01:51:26 +09:00
Nicholas Nethercote
0fb3a509cf Add warn(unreachable_pub) to rustc_target. 2024-09-03 08:49:54 +10:00
beetrees
abd44fc5f4 Add f16 and f128 inline ASM support for aarch64 2024-08-25 00:13:25 +01:00
rongfu.leng
ec67cdf98a Enable f16 in assembly on aarch64 platforms that support it
Signed-off-by: rongfu.leng <lenronfu@gmail.com>
2024-08-24 23:07:09 +01:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Jubilee Young
0d8f734172 compiler: Fix arm32 asm issues by hierarchically sorting reg classes 2024-06-22 21:39:58 -07:00
Guillaume Gomez
07e8b3ac01 Rollup merge of #126555 - beetrees:f16-inline-asm-arm, r=Amanieu
Add `f16` inline ASM support for 32-bit ARM

Adds `f16` inline ASM support for 32-bit ARM. SIMD vector types are taken from [here](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A32]).`

Relevant issue: #125398
Tracking issue: #116909

`@rustbot` label +F-f16_and_f128
2024-06-22 12:57:18 +02:00
beetrees
771e44ebd3 Add f16 inline ASM support for RISC-V 2024-06-21 18:48:20 +01:00
beetrees
753fb070bb Add f16 inline ASM support for 32-bit ARM 2024-06-21 18:26:42 +01:00
beetrees
dfc5514527 Add f16 and f128 inline ASM support for x86 and x86-64 2024-06-13 16:12:23 +01:00
Nicholas Nethercote
4814fd0a4b Remove extern crate rustc_macros from numerous crates. 2024-04-29 10:21:54 +10:00
Matthias Krüger
074269f7a1 Rollup merge of #123740 - veera-sivarajan:reduce-size-of-modifierinfo, r=petrochenkov
Reduce Size of `ModifierInfo`

I added `ModifierInfo` in #121940 and had used a `u64` for  the `size` field even though the largest value it holds is `512`.

This PR changes the type of the `size` field to `u16`.
2024-04-11 20:20:50 +02:00
Veera
791ba531c0 Reduce size of ModifierInfo 2024-04-10 15:48:22 -04:00
Daniel Paoliello
2e44d29460 Add support for Arm64EC inline assembly 2024-04-10 10:06:44 -07:00
Veera
1bde828141 Improve style 2024-03-13 19:20:49 -04:00
Veera
9aac0c9ae3 Mention Register Size in #[warn(asm_sub_register)]
Fixes #121593
2024-03-03 09:34:26 -05:00
Taiki Endo
ee41651d2f Support reg_addr register class in s390x inline assembly 2024-01-03 18:00:37 +09:00
dirreke
31daed1b64 update the registers of csky 2023-10-21 23:42:09 +08:00
Dirreke
184a9afffb add details for csky-unknown-linux-gnuabiv2 and add docs 2023-08-14 23:02:37 +08:00
Dirreke
d16409fe22 add a csky-unknown-linux-gnuabiv2 target 2023-08-14 23:02:36 +08:00
chenx97
d3727148a0 support for mips32r6 as a target_arch value 2023-07-18 18:58:18 +08:00
chenx97
a132b3ec03 merge patterns 2023-07-18 18:58:18 +08:00
chenx97
c6e03cd951 support for mips64r6 as a target_arch value 2023-07-18 18:58:18 +08:00