Skip to content

Conversation

taiki-e
Copy link
Member

@taiki-e taiki-e commented Nov 28, 2024

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

Self::freg => types! { _: F32, F64; },

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-inline-assembly Area: Inline assembly (`asm!(…)`) O-loongarch Target: LoongArch (LA32R, LA32S, LA64) labels Nov 28, 2024
@Amanieu
Copy link
Member

Amanieu commented Nov 28, 2024

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 28, 2024

📌 Commit 0c8e36b has been approved by Amanieu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 28, 2024
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Nov 30, 2024
Fix target_feature handling in freg of LoongArch inline assembly

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

https://github.com/rust-lang/rust/blob/9b4d7c6a40b328d212095c28670c629facf1557d/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
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 30, 2024
Rollup of 10 pull requests

Successful merges:

 - rust-lang#116161 (Stabilize `extended_varargs_abi_support`)
 - rust-lang#132750 ([AIX] handle libunwind native_libs)
 - rust-lang#133488 (tests: Add regression test for self referential structs with cow as last field)
 - rust-lang#133569 (Bump `ruzstd` to 0.7.3)
 - rust-lang#133585 (Do not call `extern_crate` on current trait on crate mismatch errors)
 - rust-lang#133587 (Fix target_feature handling in freg of LoongArch inline assembly)
 - rust-lang#133599 (Add `+forced-atomics` feature to esp32s2 no_std  target)
 - rust-lang#133620 (Simplify hir_typeck_pass_to_variadic_function)
 - rust-lang#133623 (Improve span handling in `parse_expr_bottom`.)
 - rust-lang#133625 (custom MIR: add doc comment for debuginfo)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 30, 2024
Rollup of 10 pull requests

Successful merges:

 - rust-lang#116161 (Stabilize `extended_varargs_abi_support`)
 - rust-lang#132750 ([AIX] handle libunwind native_libs)
 - rust-lang#133488 (tests: Add regression test for self referential structs with cow as last field)
 - rust-lang#133569 (Bump `ruzstd` to 0.7.3)
 - rust-lang#133585 (Do not call `extern_crate` on current trait on crate mismatch errors)
 - rust-lang#133587 (Fix target_feature handling in freg of LoongArch inline assembly)
 - rust-lang#133599 (Add `+forced-atomics` feature to esp32s2 no_std  target)
 - rust-lang#133620 (Simplify hir_typeck_pass_to_variadic_function)
 - rust-lang#133623 (Improve span handling in `parse_expr_bottom`.)
 - rust-lang#133625 (custom MIR: add doc comment for debuginfo)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ab4588a into rust-lang:master Nov 30, 2024
6 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Nov 30, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 30, 2024
Rollup merge of rust-lang#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.

https://github.com/rust-lang/rust/blob/9b4d7c6a40b328d212095c28670c629facf1557d/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
@taiki-e taiki-e deleted the loongarch-asm-freg branch November 30, 2024 17:26
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!(…)`) O-loongarch Target: LoongArch (LA32R, LA32S, LA64) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants