Forbid disabling SSE on x86 targets that have SSE in their "baseline" · Issue #808 · rust-lang/compiler-team (original) (raw)

Proposal

Passing -Ctarget-feature=-sse on an x86-64 target currently produces an ugly LLVM error.
Doing the same on a x86-32 target leads to unsound floating-point behavior.

Therefore, I think we should deprecate and eventually fully forbid toggling the sse/sse2 target features on x86 targets, except for those targets that do not have these features to begin with (e.g. i586-unknown-linux-gnu).

Here, compiler team triage decided "Current Tier 1 x86 targets require SSE-based floats at minimum"; this MCP is basically intended reaffirm that position with a more formal process.

I am implementing some machinery here that could help with that, but properly implementing this will be tricky since one can also use -Ctarget-cpu to disable these target features.

Once this is implemented, we have some options for improving the Rust ABI on these targets as well:

• on x86-32, we could use SSE registers to return float values, instead of PassMode::Indirect
• on all x86 targets, we could pass SIMD vectors of up to 128 bits in registers rather than indirectly

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

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

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

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.