aarch64 softfloat target: always pass floats in int registers #133102
+106
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @Nadrieril rustbot has assigned @Nadrieril. Use |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
aarch64-softfloat
branch
from
d2a6139
to
7d57c37
Compare
|
Ah, we also have to do something for ScalarPair types. The easiest thing to do is pass them indirectly, so that's what I did for now. |
RalfJung
force-pushed
the
aarch64-softfloat
branch
from
7d57c37
to
10a2a67
Compare
|
r? compiler |
|
Isn't this the second target we are manufacturing a by-integer ABI for? |
|
Is it? I am not aware of another.
|
|
x87 Rust ABI? |
|
There we are returning floats by-ptr, I think? Ah maybe we only do that for floats larger than a ptr. |
|
I am mostly musing that I should probably cross-check those cases to see if there's something that can be factored out before accepting this. |
|
For x86-32 we only do something with the return value, since arguments anyway never use the x87 stack. But yeah we could probably use the same logic for both. I am just not sure what is the best way to share that logic. |
|
OTOH we might want to change the x87 thing to use SSE registers if we can, so sharing the code might not be such a good idea. |
wesleywiser
approved these changes
Nov 20, 2024
RalfJung
force-pushed
the
aarch64-softfloat
branch
from
10a2a67
to
f484507
Compare
RalfJung
force-pushed
the
aarch64-softfloat
branch
from
f484507
to
666bcbd
Compare
|
@bors r=davidtwco,wesleywiser |
bors
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Nov 22, 2024
…dtwco,wesleywiser aarch64 softfloat target: always pass floats in int registers This is a part of rust-lang#131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI. Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that. So we follow the aarch64 [softfloat ABI](rust-lang#131058 (comment)) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection. Cc `@workingjubilee`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 22, 2024
Rollup of 13 pull requests Successful merges: - rust-lang#130867 (distinguish overflow and unimplemented in Step::steps_between) - rust-lang#131859 (Update TRPL to add new Chapter 17: Async and Await) - rust-lang#132090 (Stop being so bail-y in candidate assembly) - rust-lang#132658 (Detect const in pattern with typo) - rust-lang#133041 (Print name of env var in `--print=deployment-target`) - rust-lang#133102 (aarch64 softfloat target: always pass floats in int registers) - rust-lang#133159 (Don't allow `-Zunstable-options` to take a value ) - rust-lang#133217 ([AIX] Add option -X32_64 to the "strip" command) - rust-lang#133237 (Minimally constify `Add`) - rust-lang#133238 (re-export `is_loongarch_feature_detected`) - rust-lang#133286 (Re-delay a resolve `bug` related to `Self`-ctor in patterns) - rust-lang#133301 (Add code example for `wrapping_neg` method for signed integers) - rust-lang#133313 (Use arc4random of libc for RTEMS target) Failed merges: - rust-lang#133215 (Fix missing submodule in `./x vendor`) r? `@ghost` `@rustbot` modify labels: rollup
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Nov 22, 2024
…dtwco,wesleywiser aarch64 softfloat target: always pass floats in int registers This is a part of rust-lang#131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI. Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that. So we follow the aarch64 [softfloat ABI](rust-lang#131058 (comment)) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection. Cc ``@workingjubilee``
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 23, 2024
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#132090 (Stop being so bail-y in candidate assembly) - rust-lang#132658 (Detect const in pattern with typo) - rust-lang#132911 (Pretty print async fn sugar in opaques and trait bounds) - rust-lang#133102 (aarch64 softfloat target: always pass floats in int registers) - rust-lang#133159 (Don't allow `-Zunstable-options` to take a value ) - rust-lang#133208 (generate-copyright: Now generates a library file too.) - rust-lang#133215 (Fix missing submodule in `./x vendor`) - rust-lang#133264 (implement OsString::truncate) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 23, 2024
Rollup merge of rust-lang#133102 - RalfJung:aarch64-softfloat, r=davidtwco,wesleywiser aarch64 softfloat target: always pass floats in int registers This is a part of rust-lang#131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI. Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that. So we follow the aarch64 [softfloat ABI](rust-lang#131058 (comment)) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection. Cc ```@workingjubilee```
10 tasks
This was referenced Nov 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a part of #131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling
neoninstructions can change the ABI.Other targets have a
soft-floattarget feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that.So we follow the aarch64 softfloat ABI and treat floats like integers for
extern "C"functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection.Cc @workingjubilee