-Zmir-opt-level Reform

[wesleywiser]

-Zmir-opt-level Reform

Summary

Change the -Zmir-opt-level unstable flag to have the following possible values and associated behaviors:

• 0 - MIR optimizations are disabled.
• 1 - Some MIR optimizations are enabled.
  • This would be the default if -Zmir-opt-level is not specified.
  • Optimizations ran at this level would be selected based on their ability to improve compilation performance.
  • Optimizations ran should not hurt the debug-ability of programs.
• 2 - Many (most?) MIR optimizations are enabled.
  • Optimizations ran at this level would include any passes that improve or have no significant adverse effect on compilation performance.
  • Optimizations ran would not be required to maintain the debug-ability of programs.
• 3 - All non-experimental MIR optimizations are enabled.
  • Optimizations ran at this level may have negative impacts on compilation performance provided there is some run-time benefit.
  • As with mir-opt-level=2, optimizations would not be required to maintain the debug-ability of programs.

In addition, a new permanently unstable compiler flag is added: -Zexperimental-mir-optimizations. MIR optimizations that are still being developed or are currently too buggy to be enabled are gated under this flag which allows them to still be maintained in-tree and participate in the mir-opt testing framework.

Rationale

Currently, -Zmir-opt-level is kind of a mess.

• -Zmir-opt-level=0 disables MIR optimizations but that wasn't always the case.
• -Zmir-opt-level=1 runs some of the MIR optimizations. (This is the current default)
• -Zmir-opt-level=2 has broken MIR optimizations.
• -Zmir-opt-level=3 has slow MIR optimizaitons.

By changing -Zmir-opt-level so that we do not run experimental/broken MIR optimizations, we can eventually allow --release builds to use mir-opt-level=2 and even potentially stablize the flag, allowing stable users to opt-in to mir-opt-level=3 for cases where run-time performance is the highest priority. This MCP does not propose doing that at this time, but notes that it would be reasonable to consider those possibilities in the future if this MCP were accepted.

Mentors or Reviewers

@oli-obk has volunteered to review.

Process

The main points of the Major Change Process is 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.

[jonas-schievink]

@rustbot second

[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.

[RalfJung]

Link to Zulip stream (would be useful to have that in the OP)

EDIT: oh, it's in the bot response, I see. I was confused by the first copy of "there is a Zulip stream for that" not having the link.