-
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
Direct users towards using Rust target feature names in CLI #87402
Direct users towards using Rust target feature names in CLI #87402
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #87449) made this pull request unmergeable. Please resolve the merge conflicts. |
e15e415
to
1761c60
Compare
Hm, one remaining problem is that we call |
c32957a
to
4b66ad5
Compare
This comment has been minimized.
This comment has been minimized.
4b66ad5
to
e25afb2
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit e25afb20b11f9cc764ea5e1f6d593b504bc1807f with merge 0c190043f011023658fc263567eaf5bc76f3cb4b... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Queued 0c190043f011023658fc263567eaf5bc76f3cb4b with parent a0648ea, future comparison URL. |
Finished benchmarking commit (0c190043f011023658fc263567eaf5bc76f3cb4b): comparison url. Summary: This change led to very large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
4 digits of regression. Nice. I think I can guess what the reason is. As the Things to try: remove |
ea176be
to
69025a6
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Testing commit df701a2 with merge 7d6dc0530f5c4fcb230282f143f7ac71bedf105c... |
💥 Test timed out |
@bors retry timeout |
☀️ Test successful - checks-actions |
Finished benchmarking commit (39a3b52): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
…s-for-features, r=estebank Direct users towards using Rust target feature names in CLI This PR consists of a couple of changes on how we handle target features. In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed). The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery. And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me. Sponsored by: standard.ai
…t spec file Only a subset of the LLVM codegen features are recognized by `rustc`, and since rust-lang/rust#87402 (Rust 1.61.0) the compiler gives a warning about it: warning: unknown feature specified for `-Ctarget-feature`: `mmx` | = note: it is still passed through to the codegen backend = note: consider filing a feature request ...since those features may be renamed or removed at any point: $ rustc --print target-features [...] Code-generation features cannot be used in cfg or #[target_feature], and may be renamed or removed in a future version of LLVM or rustc. Thus move them back to the target spec generated file. See rust-lang/rust#96472 as well for a report. Signed-off-by: Miguel Ojeda <[email protected]>
…t spec file Only a subset of the LLVM codegen features are recognized by `rustc`, and since rust-lang/rust#87402 (Rust 1.61.0) the compiler gives a warning about it: warning: unknown feature specified for `-Ctarget-feature`: `mmx` | = note: it is still passed through to the codegen backend = note: consider filing a feature request ...since those features may be renamed or removed at any point: $ rustc --print target-features [...] Code-generation features cannot be used in cfg or #[target_feature], and may be renamed or removed in a future version of LLVM or rustc. Thus move them back to the target spec generated file. See rust-lang/rust#96472 as well for a report. Signed-off-by: Miguel Ojeda <[email protected]>
Add `sign-ext` target feature to the WASM target Some target features are still missing from that list. See rust-lang#97808 for basically the same PR by `@alexcrichton.` Related issue: rust-lang#96472. PR introducing this issue: rust-lang#87402.
…t spec file Similar to c5eae3a ("x86: rust: move unknown-to-`rustc` codegen features back to the target spec file"), but for `retpoline-external-thunk`: Only a subset of the LLVM codegen features are recognized by `rustc`, and since rust-lang/rust#87402 (Rust 1.61.0) the compiler gives a warning about it: warning: unknown feature specified for `-Ctarget-feature`: `mmx` | = note: it is still passed through to the codegen backend = note: consider filing a feature request ...since those features may be renamed or removed at any point: $ rustc --print target-features [...] Code-generation features cannot be used in cfg or #[target_feature], and may be renamed or removed in a future version of LLVM or rustc. Thus move them back to the target spec generated file. See rust-lang/rust#96472 as well for a report. Signed-off-by: Miguel Ojeda <[email protected]>
…t spec file Similar to c5eae3a ("x86: rust: move unknown-to-`rustc` codegen features back to the target spec file"), but for `retpoline-external-thunk`: Only a subset of the LLVM codegen features are recognized by `rustc`, and since rust-lang/rust#87402 (Rust 1.61.0) the compiler gives a warning about it: warning: unknown feature specified for `-Ctarget-feature`: `mmx` | = note: it is still passed through to the codegen backend = note: consider filing a feature request ...since those features may be renamed or removed at any point: $ rustc --print target-features [...] Code-generation features cannot be used in cfg or #[target_feature], and may be renamed or removed in a future version of LLVM or rustc. Thus move them back to the target spec generated file. See rust-lang/rust#96472 as well for a report. Signed-off-by: Miguel Ojeda <[email protected]>
This PR consists of a couple of changes on how we handle target features.
In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by
+
or-
to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g.
bmi
->bmi1
) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via#[cfg(target_feature)]
machinery. And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.Sponsored by: standard.ai