Skip to content

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
Collaborator

bors commented Nov 28, 2024

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

@bors
Copy link
Collaborator

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
Contributor

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

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.

@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
Collaborator

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 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%)

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