Add mips64r6 and mips32r6 options to target_arch

[chenx97]

Proposal

Tier-3 targets like mipsisa64r6-unknown-linux-gnuabi64 and mipsisa64r6el-unknown-linux-gnuabi64 exist because their binaries are not compatible with those of mips64-unknown-linux-gnuabi64 and mips64el-unknown-linux-gnuabi64. MIPS R6 repurposes many opcodes for new instructions and introduces new instructions occupying reserved opcodes. It even changed its multiplication and division behavior, as it now uses separated instructions for upper and lower parts of the result, stores results in GPRs instead of a special register pair, and lets the microarchitecture optimize divide-and-remainder instruction sequences and low-high multiplication instruction sequences. In short, it doesn't just make sense to treat them as different targets, but as different architectures.

The proposal is written because these targets' target_arch is "mips64", and the target_arch of 32-bit MIPS R6 targets is "mips". I'd like to change them to "mips64r6" and "mips32r6" respectively. Although "mips64" and "mips" work most of the time as both MIPS revisions share the same ABI, ioctl constants, etc., it makes rust programs difficult, if not impossible, to figure out whether they are being compiled for traditional MIPS or MIPS R6. In build.rs, you can check the TARGET or the HOST triples to see if you are targeting MIPS R6. But what if I want to conditionally enable features and dependencies in Cargo.toml?

I also explored the possibility of adding target_features instead because that follows what the backends do. We ultimately decided against it because enabling such "features" inside a mips64 program would be possible and is pure nonsense. It also challenges what a "feature" should mean semantically. Existing architecture matching logic would continue to fail unless you match features after matching the architecture, and these "features" probably wouldn't stabilize when introduced, making them less useful anyway.

Mentors or Reviewers

@bjorn3 @nagisa @workingjubilee @wesleywiser

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.

[rustbot]

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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[wesleywiser]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted