Allow overriding default codegen backend on a per-target basis

[WaffleLapkin]

Proposal

Add a field to TargetOptions, which allows overriding default codegen backend (CFG_DEFAULT_CODEGEN_BACKEND). Such that the priority for choosing codegen backend will be:

• Explicit target passed to the compiler
• Target default codegen backend (new!)
• CFG_DEFAULT_CODEGEN_BACKEND env variable
• "llvm"

This can be really helpful, given an exotic target that can only be compiled by a specific codegen backend. Full disclosure: at my {dayjob} we are working on a custom backend for rustc that supports an exotic target. This is something we'll add to our fork either way, but also would like to upstream.

---

This may not sound like a major thing, however, this creates a cyclic dependency because of target_override:

https://github.com/rust-lang/rust/blob/bf1e3f31f95c0f75b9bf51a58e8684f750f919f2/compiler/rustc_codegen_ssa/src/traits/backend.rs#L73-L76

So my current idea is to "iterate till fixpoint". Get a backend for the target, ask it for override, ask the target for backend override, ... and so on, untill the target stops changing. Note that in practice, it's unlikely that this will take more that 1 (0?) iterations, backends should return targets that either don't have an override or that have an override for the same backend.

Based on discussions in the zulip thread I've changed my opinion on this. It seems like forbidding target and backend to overwrite each other at the same time is a better idea, as it both simplifies the implementation/required changes and prevents surprising behavior.

Mentors or Reviewers

I'm planning to implement this; I don't have anyone in mind for reviews.

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

[davidtwco]

@rustbot second

[apiraino]

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