Do not remove trivial `SwitchInt` in analysis MIR #139042

compiler-errors · 2025-03-28T03:31:48Z

This PR ensures that we don't prematurely remove trivial SwitchInt terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the SimplifyCfg optimization was removing SwitchInt terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that SwitchInt terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory.

This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB.

Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like:

fn foo() {
    let x;
    let (0 | _) = x;
}

This match expression should perform a read because _ does not shadow the 0 literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: #139042 (comment)

As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like 0 | _), then we should be enabling this behavior after fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.:

fn foo() {
    let x;
    let (0.. | _) = x;
}

rustbot · 2025-03-28T03:31:52Z

r? @saethlin

rustbot has assigned @saethlin.
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

rustbot · 2025-03-28T03:31:54Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

compiler-errors · 2025-03-28T03:37:16Z

compiler/rustc_mir_transform/src/simplify.rs

-            _ => return false,
+        // Removing a `SwitchInt` terminator may remove reads that result in UB,
+        // so we must not apply this optimization when mir-opt-level = 0.
+        if self.mir_opt_level == 0 {


We could perhaps optimize trivial operands... Like plain locals. Maybe consts?

Well I guess even plain locals could have UB if they're uninitialized. But Rust would never produce that 🤔

SimplifyCfg runs before borrowck, so the following compiles:

fn main() { let bad_ref: &i32; let &(0 | _) = bad_ref; }

oh wonderful, so this is a load bearing optimization then

Ah, not just a bug for Miri then but a bigger problem. Certainly we shouldn't optimize before borrowck.

So instead of checking the mir_opt_level, this should be told which "phase" it is in (or it can maybe even get that info from the MIR body, not sure), and then not do this transformation in the "analysis" phase.

compiler-errors · 2025-03-28T05:39:47Z

well i do wonder if anything relies on this today

@bors try

…chint, r=<try> Do not remove trivial `SwitchInt` with mir-opt-level=0 When mir-opt-level=0, do not optimize out `SwitchInt` terminators that all have the same terminator since it may remove a read which affects miri's ability to detect UB on that operand. cc `@RalfJung` Fixes rust-lang/miri#4237 This affects some tests... I guess I could mark them as `mir-opt-level=1`? Not sure.

bors · 2025-03-28T05:40:59Z

⌛ Trying commit 6bad178 with merge 4dba42b...

compiler-errors · 2025-03-28T05:47:42Z

@rustbot author

src/tools/miri/tests/fail/read_from_trivial_switch.rs

bors · 2025-03-28T07:46:55Z

☀️ Try build successful - checks-actions
Build commit: 4dba42b (4dba42b29bacedb63812cd6f781e31ba4b782a95)

oli-obk · 2025-03-28T08:22:29Z

@craterbot check

craterbot · 2025-03-28T08:22:44Z

👌 Experiment pr-139042 created and queued.
🤖 Automatically detected try build 4dba42b
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

tmiasko · 2025-03-28T08:35:13Z

Pull request doesn't resolve #139042 (comment) yet and mir-opt-level=0 is never used by default. Are we getting ahead of ourselves with crater?

RalfJung · 2025-03-28T08:47:50Z

Yeah I think we do.
@craterbot cancel

The PR first needs to be changed to never do this SwitchInt removal in SimplifyCfg::Initial, SimplifyCfg::PromoteConsts, SimplifyCfg::RemoveFalseEdges, SimplifyCfg::PostAnalysis. And for SimplifyCfg::PreOptimizations it should likely be gated on mir_opt_level. Maintaining that list seems fragile so hopefully there is a better way... maybe it is checking for the phase and the opt_level.

Alternatively, instead of checking the opt level, we could have a separate flag. We already have a similar problem with RemovePlaceMention, which is now gated on the mir_keep_place_mention Z-flag. We could instead have a mir_preserve_ub Z-flag that controls both RemovePlaceMention and SimplifyCfg.

craterbot · 2025-03-28T08:50:37Z

🗑️ Experiment pr-139042 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

compiler-errors · 2025-03-30T19:02:25Z

@bors try

bors · 2025-03-30T19:03:36Z

⌛ Trying commit 01ee75d with merge 5fee451...

…chint, r=<try> Do not remove trivial `SwitchInt` with mir-opt-level=0 When mir-opt-level=0, do not optimize out `SwitchInt` terminators that all have the same terminator since it may remove a read which affects miri's ability to detect UB on that operand. cc `@RalfJung` Fixes rust-lang/miri#4237 This affects some tests... I guess I could mark them as `mir-opt-level=1`? Not sure.

bors · 2025-04-09T17:56:08Z

☀️ Try build successful - checks-actions
Build commit: 2f722cb (2f722cba6738caa1d971f6ef4229d7d86891b5af)

rust-timer · 2025-04-09T19:58:47Z

Finished benchmarking commit (2f722cb): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.7%, secondary -8.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	6.3%	[6.3%, 6.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.8%	[-4.8%, -4.8%]	1
Improvements ✅ (secondary)	-8.1%	[-8.1%, -8.1%]	1
All ❌✅ (primary)	0.7%	[-4.8%, 6.3%]	2

Cycles

Results (secondary 2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[2.2%, 3.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Bootstrap: 779.721s -> 780.808s (0.14%)
Artifact size: 366.13 MiB -> 366.15 MiB (0.01%)

compiler-errors · 2025-04-09T19:59:45Z

@bors rollup-

saethlin · 2025-04-09T20:02:48Z

My return from vacation hasn't processed yet but I'm quite interested in this PR so I've changed the assignment manually.

saethlin · 2025-04-10T00:09:16Z

I am surprised this PR is adding more complexity instead of removing all uses of SimplifyCfg outside of the optimization pass list. Why did you decide to go for this approach?

compiler-errors · 2025-04-10T00:17:15Z

Why did you decide to go for this approach?

🤷 seems pretty weird not to run the whole SimplifyCfg pass before runtime optimization. I don't consider this PR to be adding much complexity.

compiler-errors · 2025-04-10T00:26:31Z

Also, existing analysis requires that SimplifyCfg has been run.

rust/compiler/rustc_mir_transform/src/simplify.rs

Lines 11 to 13 in 934880f

    
           //! one should run it after every pass which may modify CFG in significant ways. This pass must 
        
           //! also be run before any analysis passes because it removes dead blocks, and some of these can be 
        
           //! ill-typed.

rust/compiler/rustc_mir_dataflow/src/framework/cursor.rs

Lines 143 to 144 in 934880f

    
           #[cfg(debug_assertions)] 
        
           assert!(self.reachable_blocks.contains(block));

saethlin · 2025-04-10T02:09:48Z

🤷 seems pretty weird not to run the whole SimplifyCfg pass before runtime optimization.

Why? If we are running optimizations outside of the optimization passes turning off MIR optimizations doesn't turn off all MIR optimizations. That seems bad to me. Right?

nikomatsakis · 2025-04-16T16:48:31Z

@rfcbot reviewed

compiler-errors · 2025-04-16T17:43:15Z

I'll repeat myself so the status of this PR is clear: SimplifyCfg needs to run for analysis passes as I noted above. I don't think that this PR can be simplified further, and I don't think the burden of the implementation of this PR is particularly high.

I tried implementing a separate, rudimentary RemoveRedundantSwitch pass (#139639) but that ended up not being so great perf-wise.

I think this PR should land in the state it's in today.

rfcbot · 2025-04-19T15:50:23Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

saethlin · 2025-04-19T19:00:06Z

I'll look into this more on my own time, but I think I've come around to agree with @compiler-errors.

@bors r+

bors · 2025-04-19T19:00:08Z

📌 Commit 3ee62a9 has been approved by saethlin

It is now in the queue for this repository.

…enton Rollup of 7 pull requests Successful merges: - rust-lang#139042 (Do not remove trivial `SwitchInt` in analysis MIR) - rust-lang#139533 (add next_index to Enumerate) - rust-lang#139843 (Setup editor file associations for non-rs extensions) - rust-lang#140000 (skip llvm-config in autodiff check builds, when its unavailable) - rust-lang#140008 (Improve `clean_maybe_renamed_item` function code a bit) - rust-lang#140024 (Remove early exits from JumpThreading.) - rust-lang#140039 (Add option for stable backport poll) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#139042 - compiler-errors:do-not-optimize-switchint, r=saethlin Do not remove trivial `SwitchInt` in analysis MIR This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory. This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB. Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like: ```rust fn foo() { let x; let (0 | _) = x; } ``` This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: rust-lang#139042 (comment) As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.: ```rust fn foo() { let x; let (0.. | _) = x; } ```

…r=saethlin Do not remove trivial `SwitchInt` in analysis MIR This PR ensures that we don't prematurely remove trivial `SwitchInt` terminators which affects both the borrow-checking and runtime semantics (i.e. UB) of the code. Previously the `SimplifyCfg` optimization was removing `SwitchInt` terminators when they was "trivial", i.e. when all arms branched to the same basic block, even if that `SwitchInt` terminator had the side-effect of reading an operand which (for example) may not be initialized or may point to an invalid place in memory. This behavior is unlike all other optimizations, which are only applied after "analysis" (i.e. borrow-checking) is finished, and which Miri disables to make sure the compiler doesn't silently remove UB. Fixing this code "breaks" (i.e. unmasks) code that used to borrow-check but no longer does, like: ```rust fn foo() { let x; let (0 | _) = x; } ``` This match expression should perform a read because `_` does not shadow the `0` literal pattern, and the compiler should have to read the match scrutinee to compare it to 0. I've checked that this behavior does not actually manifest in practice via a crater run which came back clean: rust-lang/rust#139042 (comment) As a side-note, it may be tempting to suggest that this is actually a good thing or that we should preserve this behavior. If we wanted to make this work (i.e. trivially optimize out reads from matches that are redundant like `0 | _`), then we should be enabling this behavior *after* fixing this. However, I think it's kinda unprincipled, and for example other variations of the code don't even work today, e.g.: ```rust fn foo() { let x; let (0.. | _) = x; } ```

rustbot assigned saethlin Mar 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 28, 2025

compiler-errors commented Mar 28, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 28, 2025

compiler-errors unassigned saethlin Mar 28, 2025

RalfJung reviewed Mar 28, 2025

View reviewed changes

src/tools/miri/tests/fail/read_from_trivial_switch.rs Show resolved Hide resolved

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 28, 2025

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Mar 28, 2025

compiler-errors force-pushed the do-not-optimize-switchint branch from 6bad178 to 01ee75d Compare March 30, 2025 19:01

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 9, 2025

saethlin assigned saethlin and unassigned RalfJung Apr 9, 2025

traviscross removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Apr 16, 2025

rustbot mentioned this pull request Apr 19, 2025

Tracking issue for release notes of #139042: Do not remove trivial SwitchInt in analysis MIR #140045

Open

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 19, 2025

ChrisDenton mentioned this pull request Apr 19, 2025

Rollup of 7 pull requests #140053

Merged

bors merged commit 5d2375f into rust-lang:master Apr 20, 2025
7 checks passed

rustbot added this to the 1.88.0 milestone Apr 20, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Do not remove trivial `SwitchInt` in analysis MIR #139042

Do not remove trivial `SwitchInt` in analysis MIR #139042

compiler-errors commented Mar 28, 2025 •

edited

Loading

rustbot commented Mar 28, 2025

rustbot commented Mar 28, 2025

compiler-errors Mar 28, 2025

compiler-errors Mar 28, 2025

tmiasko Mar 28, 2025

compiler-errors Mar 28, 2025

RalfJung Mar 28, 2025

This comment has been minimized.

compiler-errors commented Mar 28, 2025

bors commented Mar 28, 2025

compiler-errors commented Mar 28, 2025

bors commented Mar 28, 2025

oli-obk commented Mar 28, 2025

craterbot commented Mar 28, 2025

tmiasko commented Mar 28, 2025

RalfJung commented Mar 28, 2025

craterbot commented Mar 28, 2025

compiler-errors commented Mar 30, 2025

bors commented Mar 30, 2025

This comment has been minimized.

bors commented Apr 9, 2025

This comment has been minimized.

rust-timer commented Apr 9, 2025

compiler-errors commented Apr 9, 2025

saethlin commented Apr 9, 2025

saethlin commented Apr 10, 2025 •

edited

Loading

compiler-errors commented Apr 10, 2025

compiler-errors commented Apr 10, 2025

saethlin commented Apr 10, 2025

nikomatsakis commented Apr 16, 2025

compiler-errors commented Apr 16, 2025

rfcbot commented Apr 19, 2025

saethlin commented Apr 19, 2025

bors commented Apr 19, 2025

Do not remove trivial SwitchInt in analysis MIR #139042

Do not remove trivial SwitchInt in analysis MIR #139042

Conversation

compiler-errors commented Mar 28, 2025 • edited Loading

rustbot commented Mar 28, 2025

rustbot commented Mar 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

compiler-errors commented Mar 28, 2025

bors commented Mar 28, 2025

compiler-errors commented Mar 28, 2025

bors commented Mar 28, 2025

oli-obk commented Mar 28, 2025

craterbot commented Mar 28, 2025

tmiasko commented Mar 28, 2025

RalfJung commented Mar 28, 2025

craterbot commented Mar 28, 2025

compiler-errors commented Mar 30, 2025

bors commented Mar 30, 2025

This comment has been minimized.

bors commented Apr 9, 2025

This comment has been minimized.

rust-timer commented Apr 9, 2025

Overall result: no relevant changes - no action needed

compiler-errors commented Apr 9, 2025

saethlin commented Apr 9, 2025

saethlin commented Apr 10, 2025 • edited Loading

compiler-errors commented Apr 10, 2025

compiler-errors commented Apr 10, 2025

saethlin commented Apr 10, 2025

nikomatsakis commented Apr 16, 2025

compiler-errors commented Apr 16, 2025

rfcbot commented Apr 19, 2025

saethlin commented Apr 19, 2025

bors commented Apr 19, 2025

Do not remove trivial `SwitchInt` in analysis MIR #139042

Do not remove trivial `SwitchInt` in analysis MIR #139042

compiler-errors commented Mar 28, 2025 •

edited

Loading

saethlin commented Apr 10, 2025 •

edited

Loading