Add -Zllvm-target-feature to pass features directly to LLVM#159545
Add -Zllvm-target-feature to pass features directly to LLVM#159545fo40225 wants to merge 1 commit into
Conversation
Implement MCP 994 (tracking issue 157753): a new unstable flag `-Zllvm-target-feature` that forwards comma-separated `+feat`/`-feat` strings verbatim to the LLVM backend, bypassing Rust's known-feature table. The flag is registered as a target modifier, so mixing different values across crates is an error unless overridden with `-Cunsafe-allow-abi-mismatch=llvm-target-feature`. Non-LLVM backends ignore it, like `-Cllvm-args`. As part of the deprecation path, the warning for unknown features passed via `-Ctarget-feature` now notes that this will become a hard error in a future release and points to `-Zllvm-target-feature` instead.
rustbot
added
A-LLVM
|
Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @nnethercote (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
There was a problem hiding this comment.
The warning-based passthrough is unsound to rely on
I do not understand what you mean by "unsound" here, @fo40225.
It is undesirable to rely on.
Passing target features at all, however, is simply prone to being unsound, because LLVM can have arbitrary semantics for "target features" that do not accord with the model adopted for Rust target features. It is not relying on the passthrough that is unsound.
Anyways, please rewrite your entire PR description for conciseness. Or, if you had something else "write" it, then actually do so for the first time. Either way, I do not need to be regaled with the minutiae of every test if I can read the code. That entire PR description will become a commit in our repo, so please account for people staring at it in their terminal window after tapping out git status.
Also, please split out the addition of the future compatibility warning. This does not need to, and should not, all happen in one PR. Make this add -Zllvm-target-feature only.
| features in the form `+feat` or `-feat`, for example: | ||
|
|
||
| ```sh | ||
| rustc -Zllvm-target-feature=+prefer-256-bit main.rs |
There was a problem hiding this comment.
Example should exemplify the multi-feature case (either in the same invocation or in another).
| ``` | ||
|
|
||
| Each feature string is forwarded verbatim to LLVM. This allows using LLVM target features | ||
| that are not (or not yet) part of Rust's target feature system, for example to match the |
There was a problem hiding this comment.
This can be less ambiguous: some things LLVM calls "target features" should never be part of ours, because they e.g. are incoherent with target_feature(enable), which allows adding them on a per-function basis, and only make sense as whole-program modifiers.
rustbot
added
S-waiting-on-author
|
|
4 participants
Summary
Implement rust-lang/compiler-team#994: add a new unstable flag
-Zllvm-target-featurethat forwards comma-separated+feat/-featstrings verbatim to the LLVM backend, bypassing rustc's known-feature table.Tracking issue: #157753
Motivation
-Ctarget-featurecurrently serves two purposes: toggling Rust-recognized target features, and (with a warning) forwarding arbitrary unknown strings to LLVM.The warning-based passthrough is unsound to rely on and unacceptable for users who need raw LLVM features (e.g. matching the ABI of foreign libraries built with features Rust does not model, such as MIPS
nan2008), forcing them onto unstable JSON target specs instead.MCP 994 splits the two concerns: a dedicated, explicitly-unsafe-ish escape hatch for LLVM-level features, and a deprecation path for the old passthrough.
What this PR does
-Zllvm-target-feature=<+feat,-feat,...>(unstable): each segment is appended verbatim to the LLVM feature list inllvm_features_by_flags, after all other flag-derived features.It does not affect
cfg(target_feature)or runtime feature detection, and non-LLVM backends ignore it (same stance as-Cllvm-args).No validation is performed; invalid names surface as LLVM's own "not a recognized feature" diagnostics.
[TRACKED] { TARGET_MODIFIER: LlvmTargetFeature }, so linking crates compiled with different values is an error by default (E-target-modifier machinery), overridable with-Cunsafe-allow-abi-mismatch=llvm-target-feature.-Ctarget-featurenow carries two extra notes that this will become a hard error in a future release, and to use-Zllvm-target-featureinstead.compiler-flags/llvm-target-feature.md.Tests
tests/ui/target_modifiers/incompatible_llvm_target_feature.rs(+ auxiliary crate): mismatch error,-Cunsafe-allow-abi-mismatchoverride, and missing-value revisions, mirroringincompatible_regparm.rs.tests/codegen-llvm/llvm-target-feature.rs: verifies a raw LLVM-only feature (+prefer-256-bit) reaches the"target-features"function attribute.tests/ui/target-feature/similar-feature-suggestion.stderrfor the new deprecation notes.