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

reject aarch64 target feature toggling that would change the float ABI #133417

Merged
merged 4 commits into from
Dec 15, 2024

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Nov 24, 2024

Stacked on top of #133099. Only the last two commits are new.

The first new commit lays the groundwork for separately controlling whether a feature may be enabled or disabled. The second commit uses that to make it illegal to disable the neon feature (which is only possible via -Ctarget-feature, and so the new check just adds a warning). Enabling the neon feature remains allowed on targets that don't disable neon or fp-armv8, which is all our built-in targets. This way, the entire PR is not a breaking change.

Fixes #131058 for hardfloat targets (together with #133102 which fixed it for softfloat targets).

Part of #116344.

@rustbot
Copy link
Collaborator

rustbot commented Nov 24, 2024

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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. labels Nov 24, 2024
@rustbot
Copy link
Collaborator

rustbot commented Nov 24, 2024

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

These commits modify compiler targets.
(See the Target Tier Policy.)

&& !target.has_neg_feature("fp-armv8")
&& !target.has_neg_feature("neon")
{
// neon is enabled by default, and has not been disabled, so enabling it again
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know where LLVM sets neon by default, so this claim is based on hearsay.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh interesting, this is triggered in an existing test...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what happens here is that the flag is -Ctarget-feature=-neon,+sve2, and sve2 implies neon. So it makes little sense to say -neon here. I think it's fine to show a warning (and eventually hard error) for that.

The alternative would be to have a completely different approach for this entire "forbidden features" thing, where we look at the final state of all features, not at the individual enabled/disabled features. But that seems a lot more complicated and requires hooking deeper into the backend.

@bors
Copy link
Contributor

bors commented Nov 28, 2024

☔ The latest upstream changes (presumably #133568) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Dec 3, 2024

☔ The latest upstream changes (presumably #133770) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung
Copy link
Member Author

#133099 got approved, so I rebased this and it should be ready for review @compiler-errors.

Or @workingjubilee do you want to take this?

@compiler-errors
Copy link
Member

r? workingjubilee or reassign to me if you don't want to review it

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

slightly nitty. seems fine, small question

compiler/rustc_target/src/target_features.rs Show resolved Hide resolved
compiler/rustc_target/src/target_features.rs Outdated Show resolved Hide resolved
Comment on lines +337 to +338
&& !target.has_neg_feature("fp-armv8")
&& !target.has_neg_feature("neon")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these will only show up due to the target spec json, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They could also show up in future builtin targets. I want to future-proof against that since I can't expect everyone adding builtin targets to be aware of all the subtleties here.

compiler/rustc_target/src/spec/mod.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/spec/mod.rs Show resolved Hide resolved
@workingjubilee
Copy link
Member

re: is_some_and that is also nicer! thank you.

I obviously have a bad(?) case of combinator-brain.

Copy link
Member

@workingjubilee workingjubilee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anyways the exact placement of such a remark can be deferred if you think otherwise, so!

r=me with the comment or not

Co-authored-by: Jubilee <workingjubilee@gmail.com>
@RalfJung
Copy link
Member Author

I have moved the comment to the features field itself.

@bors r=workingjubilee

@bors
Copy link
Contributor

bors commented Dec 15, 2024

📌 Commit 74e2ac4 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 15, 2024
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Dec 15, 2024
@bors
Copy link
Contributor

bors commented Dec 15, 2024

⌛ Testing commit 74e2ac4 with merge d185062...

@bors
Copy link
Contributor

bors commented Dec 15, 2024

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing d185062 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 15, 2024
@bors bors merged commit d185062 into rust-lang:master Dec 15, 2024
7 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 15, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (d185062): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.4% [-0.4%, -0.3%] 2
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -2.9%, secondary -2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.9% [-4.6%, -1.3%] 2
Improvements ✅
(secondary)
-2.5% [-3.0%, -2.0%] 2
All ❌✅ (primary) -2.9% [-4.6%, -1.3%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 769.875s -> 770.653s (0.10%)
Artifact size: 333.19 MiB -> 333.19 MiB (-0.00%)

@RalfJung RalfJung deleted the aarch64-float-abi branch December 15, 2024 21:58
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Dec 16, 2024
…workingjubilee

reject unsound toggling of RISCV target features

~~Stacked on top of rust-lang#133417, only the last commit is new.~~

Works towards rust-lang#132618 (but more [remains to be done](rust-lang#134337 (comment)))
Part of rust-lang#116344

Cc `@beetrees` I hope I got everything.  I didn't do anything about "The f and zfinx features are incompatible" and that's not an ABI thing (right?) and I am not sure how to handle it with these ABI checks.
r? `@workingjubilee`

Ideally we'd also reject target specs that disable the `f` feature but set an ABI that requires `f`... but I don't want to duplicate this logic. I have some ideas for how maybe the entire float ABI check logic should be different, now that we have some examples of what these ABI checks look like, but that will be a future PR.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 16, 2024
…workingjubilee

reject unsound toggling of RISCV target features

~~Stacked on top of rust-lang#133417, only the last commit is new.~~

Works towards rust-lang#132618 (but more [remains to be done](rust-lang#134337 (comment)))
Part of rust-lang#116344

Cc ``@beetrees`` I hope I got everything.  I didn't do anything about "The f and zfinx features are incompatible" and that's not an ABI thing (right?) and I am not sure how to handle it with these ABI checks.
r? ``@workingjubilee``

Ideally we'd also reject target specs that disable the `f` feature but set an ABI that requires `f`... but I don't want to duplicate this logic. I have some ideas for how maybe the entire float ABI check logic should be different, now that we have some examples of what these ABI checks look like, but that will be a future PR.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 16, 2024
Rollup merge of rust-lang#134337 - RalfJung:riscv-target-features, r=workingjubilee

reject unsound toggling of RISCV target features

~~Stacked on top of rust-lang#133417, only the last commit is new.~~

Works towards rust-lang#132618 (but more [remains to be done](rust-lang#134337 (comment)))
Part of rust-lang#116344

Cc ``@beetrees`` I hope I got everything.  I didn't do anything about "The f and zfinx features are incompatible" and that's not an ABI thing (right?) and I am not sure how to handle it with these ABI checks.
r? ``@workingjubilee``

Ideally we'd also reject target specs that disable the `f` feature but set an ABI that requires `f`... but I don't want to duplicate this logic. I have some ideas for how maybe the entire float ABI check logic should be different, now that we have some examples of what these ABI checks look like, but that will be a future PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

The (stable) neon aarch64 target feature is unsound: it changes the float ABI
6 participants