mir-transform: Treat optimize(none) the same as opt-level=0

[clubby789]

View all comments

cc @RalfJung

[clubby789]

Typo error caused an ICE in drop elaboration

- optimizations.0 >= min_level
+ optimizations.0 < min_level

which seems a bit surprising

EDIT: Seems like some other opts rely on SimplifyCfg removing dead BBs. Not sure if we need to factor that into the pass handling? Probably fine to ignore in this PR

[clubby789]

Note that this now fails because

#[optimize(none)]
pub fn const_branch() -> i32 {
    if true { 1 } else { 0 }
}

produces return 1

[RalfJung]

EDIT: Seems like some other opts rely on SimplifyCfg removing dead BBs. Not sure if we need to factor that into the pass handling? Probably fine to ignore in this PR

What do you mean by "rely" here and why does this become more of a problem with this PR?

[clubby789]

What do you mean by "rely" here

I didn't look into it deeply, but a few passes seemed to ICE if they ran with dead BBs.

and why does this become more of a problem with this PR?

It doesn't; I just made a typo during implementation which exposed this and I was unsure if that was intentional/known.

[RalfJung]

It doesn't; I just made a typo during implementation which exposed this and I was unsure if that was intentional/known.

We'd have to ask the people that wrote the passes, so it'd help if you had a concrete example and backtrace. I presume this can be reproduced with -Zmir-enable-passes already on nightly?

[clubby789]

The ICE is from a debug assertion; with the typo reverted, and debug-assertions enabled, the ICE is as follows (when building std) rustc-ice-2026-08-10T06_58_41-132370.txt

Minimised to a baseline rustc with debug assertions:

// rustc ice.rs -Zmir-enable-passes=-SimplifyCfg-initial,-SimplifyCfg-promote-consts,-SimplifyCfg-post-analysis
fn mir_drop<T>(_place: T) {
    panic!()
}

fn main() {
    mir_drop(());
}

Not sure if this is a problem at all in practice? If you think it is I can split out a new issue since it's not too relevant to this PR specifically

[RalfJung]

Thanks! Could you file an issue? Then we can ping some folks to see what the expected contract for these passes is.

[clubby789]

Refactored around this API:

impl PassPolicy {
    /// Create a [`PassPolicy::Optional`] that is not an optimization,
    /// enabled by default under the given condition.
    pub(crate) fn optional_non_optimization(enabled_by_default: bool) -> Self;

    /// Create a [`PassPolicy::Optional`] optimization enabled at the given MIR optimization level.
    pub(crate) fn optimization(ctx: &PassCtx<'_>, min_mir_opt_level: usize) -> Self;

    /// Add another condition to an optional pass's default enablement.
    pub(crate) fn and_enabled(self, enabled: bool) -> Self;

    /// Add a minimum mir-opt-level to an optional pass.
    /// Will panic if used on a required pass.
    fn with_min_mir_opt_level(self, ctx: &PassCtx<'_>, min_mir_opt_level: usize) -> Self ;

[RalfJung]

I am not sure that PassPolicy::optimization(ctx, 2) is really more readable than PassPolicy::optimization(ctx.mir_opt_level() >= 2). The meaning of the "2" becomes rather opaque.

[rustbot]

Some changes occurred in coverage instrumentation.

cc @Zalathar

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, mir, mir-opt
• compiler, mir, mir-opt expanded to 75 candidates
• Random selection from 16 candidates

[clubby789]

I dropped the optimization method, since it's generally easier to just have an optional constructor which can take a ctx.mir_opt_level() comparison. I also updated the opt-none test to something that is no longer optimised at level 0.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[RalfJung]

This is still "waiting for author"... what is left to do here?

[clubby789]

I think
@rustbot ready
after reverting that part

[RalfJung]

Thanks. :)

@bors r+

[rust-bors]

📌 Commit 13b81b7 has been approved by RalfJung

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: RalfJung
Duration: 3h 8m 20s
Pushing f248f40 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing f207aa3 (parent) -> f248f40 (this PR)

Test differences

Show 10 test diffs

10 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f248f4038796913873f11ca65b1b901e311c8dae --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. i686-gnu-nopt-2: 1h 17m -> 2h 22m (+84.2%)
2. x86_64-gnu-llvm-21-2: 1h 8m -> 1h 44m (+51.4%)
3. dist-x86_64-solaris: 1h 42m -> 1h 3m (-37.7%)
4. x86_64-gnu-llvm-21-1: 1h 1m -> 38m 41s (-36.6%)
5. x86_64-msvc-ext3: 1h 27m -> 1h 58m (+35.0%)
6. dist-i586-gnu-i586-i686-musl: 21m 30s -> 28m 17s (+31.6%)
7. dist-powerpc-linux: 1h 15m -> 1h 36m (+26.9%)
8. x86_64-msvc-1: 2h 52m -> 2h 6m (-26.8%)
9. dist-armhf-linux: 1h 12m -> 1h 31m (+26.4%)
10. x86_64-gnu-nopt: 1h 51m -> 2h 20m (+25.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (f248f40): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary 2.7%, secondary -2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.1%, 3.6%]	3
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.3%	[-6.3%, -6.3%]	1
All ❌✅ (primary)	2.7%	[2.1%, 3.6%]	3

Cycles

Results (primary -2.2%, secondary -2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	1
All ❌✅ (primary)	-2.2%	[-2.2%, -2.2%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 476.209s -> 476.686s (0.10%)
Artifact size: 403.34 MiB -> 403.40 MiB (0.02%)