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

Add a notion of "some ABIs require certain target features" #134794

Merged
merged 7 commits into from
Jan 6, 2025

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Dec 26, 2024

I think I finally found the right shape for the data and checks that I recently added in #133099, #133417, #134337: we have a notion of "this ABI requires the following list of target features, and it is incompatible with the following list of target features". Both -Ctarget-feature and #[target_feature] are updated to ensure we follow the rules of the ABI. This removes all the "toggleability" stuff introduced before, though we do keep the notion of a fully "forbidden" target feature -- this is needed to deal with target features that are actual ABI switches, and hence are needed to even compute the list of required target features.

We always explicitly (un)set all required and in-conflict features, just to avoid potential trouble caused by the default features of whatever the base CPU is. We do this before applying -Ctarget-feature to maintain backward compatibility; this poses a slight risk of missing some implicit feature dependencies in LLVM but has the advantage of not breaking users that deliberately toggle ABI-relevant target features. They get a warning but the feature does get toggled the way they requested.

For now, our logic supports x86, ARM, and RISC-V (just like the previous logic did). Unsurprisingly, RISC-V is the nicest. ;)

As a side-effect this also (unstably) allows enabling x87 when that is harmless. I used the opportunity to mark SSE2 as required on x86-64, to better match the actual logic in LLVM and because all x86-64 chips do have SSE2. This infrastructure also prepares us for requiring SSE on x86-32 when we want to use that for our ABI (and for float semantics sanity), see #133611, but no such change is happening in this PR.

r? @workingjubilee

@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2024

Could not assign reviewer from: workingjubilee.
User(s) workingjubilee are either the PR author, already assigned, or on vacation, and there are no other candidates.
Use r? to specify someone else to assign.

@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2024

r? @davidtwco

rustbot has assigned @davidtwco.
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 Dec 26, 2024
@rustbot
Copy link
Collaborator

rustbot commented Dec 26, 2024

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

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from 849fb06 to a25cfb0 Compare December 26, 2024 19:43
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from a25cfb0 to e89c9ff Compare December 26, 2024 20:50
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from e89c9ff to c221672 Compare December 26, 2024 21:34
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from c221672 to b144ab7 Compare December 26, 2024 22:11
@workingjubilee
Copy link
Member

I will get around to this, I just put a freeze on my queue because I was accumulating enough reviews in addition to ongoing patch series. :P

// Embedded ABI, requires e.
(&["e"], &[])
}
"ilp32" | "lp64" => NOTHING,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
"ilp32" | "lp64" => NOTHING,
"ilp32" | "lp64" => {
// Incompatible with e.
(&[], &["e"])
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah right the old logic treated all the non-e ABIs the same, we should keep that.

The old logic also allowed disabling e when using an e ABI, so we should probably keep that, too.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from b144ab7 to 7563d57 Compare December 27, 2024 08:43
@RalfJung
Copy link
Member Author

@ojeda wrote

(currently, arm64 in the kernel uses --target=aarch64-unknown-none -Ctarget-feature="-neon").

That no longer works after this PR (neon is a required ABI feature so it cannot be disabled with -Ctarget-feature)... so I probably need to at least slightly adjust my strategy here.

Comment on lines 855 to 773
// We support 2 ABIs, hardfloat (default) and softfloat.
if self.has_feature("soft-float") {
NOTHING
Copy link
Member Author

Choose a reason for hiding this comment

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

It seems like this might be wrong, and we should be checking self.abi instead... but I am not sure yet.

Comment on lines 775 to 780
for feature in abi_enable {
all_rust_features.push((true, feature));
}
for feature in abi_disable {
all_rust_features.push((false, feature));
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the part where we explicitly set the ABI-relevant features. The concern here is on the one hand not knowing the default target features, and also not being entirely sure that we correctly model all "implied features" on the LLVM side.

Currently this adds the ABI-relevant features after the ones from -Ctarget-features, i.e. we are overriding the user here. That's a massive change in behavior. I feel I should probably swap the order, but then we are not protected against unexpected feature implications any more. Still, we probably want the target modifier story to be more solidified before we do any behavior changes here.

@RalfJung
Copy link
Member Author

That no longer works after this PR (neon is a required ABI feature so it cannot be disabled with -Ctarget-feature)... so I probably need to at least slightly adjust my strategy here.

I changed this to add the ABI features before the user-defined features, so things will behave as before with -Ctarget-feature=-neon on ARM targets. However, a warning is shown since this is not a supported combination -- long-term we want to forbid disabling neon on targets that need float registers for their ABI.

@rust-log-analyzer

This comment has been minimized.

@tgross35
Copy link
Contributor

I changed this to add the ABI features before the user-defined features, so things will behave as before with -Ctarget-feature=-neon on ARM targets. However, a warning is shown since this is not a supported combination -- long-term we want to forbid disabling neon on targets that need float registers for their ABI.

Could we instead add a -nofloat version of these targets? Or provide a compiler way to disable all use of float types with a build-std config to go with it.

@bors
Copy link
Contributor

bors commented Dec 31, 2024

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

@RalfJung RalfJung force-pushed the abi-required-target-features branch from 958f3f3 to 8799588 Compare December 31, 2024 11:20
@RalfJung RalfJung force-pushed the abi-required-target-features branch from 8799588 to 43ede97 Compare December 31, 2024 11:41
@RalfJung RalfJung removed the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Dec 31, 2024
@RalfJung
Copy link
Member Author

Rebased now that #134932 landed; the ARM code here now is very clean. We don't even have to mark soft-float as a "forbidden feature" any more. X86 is okay from a soundness perspective (by refusing to ever toggle the soft-float feature); aarch64 is a sad mess that I think we can only fix by refusing to toggle neon on our softfloat target -- this PR doesn't do that as I want this PR to not be a breaking change.

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.

thank you! this does look a lot nicer overall. only a small nit or three (as most of the "review" of "how even to proceed?" happened on Zulip already)

compiler/rustc_codegen_gcc/src/gcc_util.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/target_features.rs Outdated Show resolved Hide resolved
compiler/rustc_target/src/target_features.rs Show resolved Hide resolved
compiler/rustc_target/src/target_features.rs Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@RalfJung RalfJung force-pushed the abi-required-target-features branch from 887803d to 2e64b53 Compare January 5, 2025 09:46
@workingjubilee
Copy link
Member

Wonderful! @bors r+

@bors
Copy link
Contributor

bors commented Jan 5, 2025

📌 Commit 2e64b53 has been approved by workingjubilee

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 Jan 5, 2025
@bors
Copy link
Contributor

bors commented Jan 5, 2025

⌛ Testing commit 2e64b53 with merge feb32c6...

@bors
Copy link
Contributor

bors commented Jan 6, 2025

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 6, 2025
@bors bors merged commit feb32c6 into rust-lang:master Jan 6, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Jan 6, 2025
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (feb32c6): comparison URL.

Overall result: ❌ regressions - 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.3% [0.3%, 0.3%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -1.7%, secondary 0.6%)

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)
1.3% [0.5%, 2.7%] 6
Improvements ✅
(primary)
-1.7% [-2.3%, -1.2%] 8
Improvements ✅
(secondary)
-1.7% [-1.7%, -1.7%] 2
All ❌✅ (primary) -1.7% [-2.3%, -1.2%] 8

Cycles

Results (secondary 1.7%)

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)
1.7% [1.7%, 1.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

Results (primary 0.0%, secondary 0.1%)

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.0% [0.0%, 0.0%] 4
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.0%] 4

Bootstrap: 763.545s -> 762.625s (-0.12%)
Artifact size: 325.56 MiB -> 325.60 MiB (0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs 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.

10 participants