Add `-Zllvm-target-feature` target *modifier* to directly set LLVM-level target features, and deprecate doing that with `-Ctarget-feature`

[RalfJung]

Proposal

-Ctarget-feature is currently used for two somewhat different roles:

• To set Rust target features (i.e. target features listed in this table). These often but not always have the same name as LLVM target features.
• To directly set LLVM target features. Any feature not recognized by that table is forwarded verbatim to the backend with a warning.

Things work this way because a long time ago we decided that LLVM target features should be exposed by rustc even if we haven't officially stabilized them -- there's just too many of them to have everyone wait until we slowly stabilize. However, the problem with this approach is that we allow mixing different values for -Ctarget-feature in the same binary, which can be unsound as LLVM target features can affect the ABI. Consequently, we emit a warning. That warning is a no-go for the Linux kernel folks so they use a JSON target spec to configure their x86 target features. JSON target specs are incredibly unstable and having the kernel rely on that is Suboptimal, which motivates the introduction of an alternative mechanism for setting LLVM-level target features.

So, I propose we add a new flag, initially -Zllvm-target-feature (and eventually -Mllvm-target-feature or -Tllvm-target-feature if we go with one of those conventions for target modifiers), that just directly forwards target features to LLVM. We register this flag as a target modifier to avoid potential ABI issues. We also change the warning emitted for unknown features in -Ctarget-feature to be explicitly a future-compat warning, and eventually we make unknown features in -Ctarget-feature a hard error.

The main thing to figure out / bikeshed is the name of the flag. As-is, it ignores the existence of other codegen backends. OTOH, that is consistent with -Cllvm-args. Also, the names of target features differ across backends (that's one reason why we now have a concept of "Rust feature names"). So while we could call it -Zcodegen-target-feature, the value would have to be adjusted to match the active codegen backend (and when mixing different codegen backends in the same binary, we'd still force the same string to be used for all of them).

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[WaffleLapkin]

@rustbot second

[rustbot]

The final comment period is now complete, this major change is now accepted. 🎉

As the automated representative, I want to express gratitude to the author for their work and everyone else who contributed to this major change proposal.

If you think this major change shouldn't have been accepted, feel free to remove the major-change-accepted label and reopen this issue.

Note

Further progress is now tracked over at rust-lang/rust#157753.