-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Conversation
rustbot has assigned @compiler-errors. Use |
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 These commits modify compiler targets. |
&& !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 |
There was a problem hiding this comment.
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.
0fb4919
to
42db03b
Compare
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
☔ The latest upstream changes (presumably #133568) made this pull request unmergeable. Please resolve the merge conflicts. |
42db03b
to
6cd9e62
Compare
☔ The latest upstream changes (presumably #133770) made this pull request unmergeable. Please resolve the merge conflicts. |
6cd9e62
to
e9967b9
Compare
#133099 got approved, so I rebased this and it should be ready for review @compiler-errors. Or @workingjubilee do you want to take this? |
r? workingjubilee or reassign to me if you don't want to review it |
e9967b9
to
1f8236d
Compare
There was a problem hiding this 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
&& !target.has_neg_feature("fp-armv8") | ||
&& !target.has_neg_feature("neon") |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
re: I obviously have a bad(?) case of combinator-brain. |
There was a problem hiding this 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
8094e84
to
35b0e35
Compare
Co-authored-by: Jubilee <workingjubilee@gmail.com>
35b0e35
to
74e2ac4
Compare
I have moved the comment to the @bors r=workingjubilee |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d185062): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis 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.
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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 769.875s -> 770.653s (0.10%) |
…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.
…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.
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.
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 theneon
feature remains allowed on targets that don't disableneon
orfp-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.