Skip to content

Comments

compiler: Require mir_opt_level > 1 for SingleUseConsts MIR pass#151426

Open
Enselic wants to merge 1 commit intorust-lang:mainfrom
Enselic:single-use-consts-mir-opt-level
Open

compiler: Require mir_opt_level > 1 for SingleUseConsts MIR pass#151426
Enselic wants to merge 1 commit intorust-lang:mainfrom
Enselic:single-use-consts-mir-opt-level

Conversation

@Enselic
Copy link
Member

@Enselic Enselic commented Jan 20, 2026 •
edited
Loading

The default MIR opt level is 1 for non-optimized builds:

rust/compiler/rustc_session/src/session.rs

Line 581 in 0db0acd

.unwrap_or_else(|| if self.opts.optimize != OptLevel::No { 2 } else { 1 })

Require mir_opt_level > 1 for SingleUseConsts MIR pass to make tests/debuginfo/basic-stepping.rs work again which builds with debuginfo but without optimizations. That test regressed when a precursor to SingleUseConsts was enabled. Well, the test didn't exist back then (I added it in #144876), but if it had existed, it would have regressed. The pass was first called ConstDebugInfo before it was rebirthed as SingleUseConsts.

This takes us one step closer towards closing #33013.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 20, 2026
@rust-log-analyzer

This comment has been minimized.

Sign in to view
@Enselic Enselic changed the title compiler: Require mir-opt-level > 2 for SingleUseConsts compiler: Require mir-opt-level > 1 for SingleUseConsts Jan 20, 2026
@Enselic Enselic force-pushed the single-use-consts-mir-opt-level branch from 3c16dbc to 2be3ec0 Compare January 20, 2026 19:51
@Enselic Enselic mentioned this pull request Jan 21, 2026
Merged
@Enselic Enselic force-pushed the single-use-consts-mir-opt-level branch from 2be3ec0 to 6b292c7 Compare January 21, 2026 05:47
@Enselic Enselic changed the title compiler: Require mir-opt-level > 1 for SingleUseConsts compiler: Require mir-opt-level > 1 for SingleUseConsts Jan 21, 2026
@Enselic Enselic changed the title compiler: Require mir-opt-level > 1 for SingleUseConsts compiler: Require mir-opt-level > 1 for SingleUseConsts Jan 21, 2026
@rust-bors

This comment has been minimized.

Sign in to view
@Enselic Enselic force-pushed the single-use-consts-mir-opt-level branch from 6b292c7 to d7fffab Compare January 22, 2026 05:15
@Enselic Enselic changed the title compiler: Require mir-opt-level > 1 for SingleUseConsts compiler: Require mir_opt_level > 1 for SingleUseConsts MIR pass Jan 22, 2026
@Enselic Enselic marked this pull request as ready for review January 22, 2026 06:39
@rustbot
Copy link
Collaborator

rustbot commented Jan 22, 2026

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 22, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 22, 2026

r? @chenyukang

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

@Enselic

This comment was marked as outdated.

Sign in to view
@rustbot 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 Jan 23, 2026
@chenyukang
Copy link
Member

chenyukang commented Feb 10, 2026

@rustbot reroll

@rustbot rustbot assigned matthewjasper and unassigned chenyukang Feb 10, 2026
@Enselic Enselic mentioned this pull request Feb 14, 2026
Merged
@Enselic

This comment was marked as outdated.

Sign in to view
@Enselic Enselic force-pushed the single-use-consts-mir-opt-level branch from d7fffab to 9eabf52 Compare February 16, 2026 17:29
@rustbot

This comment has been minimized.

Sign in to view
@Enselic Enselic mentioned this pull request Feb 16, 2026
Merged
jhpratt added a commit to jhpratt/rust that referenced this pull request Feb 18, 2026
@jhpratt
Rollup merge of rust-lang#152729 - Enselic:single_use_consts-not-requ…
7f8c8e9 
…ired, r=cjgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang#107404 which was the precursor to `SingleUseConsts` (see rust-lang#125910 for the switch).
* By following the advice from rust-lang#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang#151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks rust-lang#151426.
jhpratt added a commit to jhpratt/rust that referenced this pull request Feb 18, 2026
@jhpratt
Rollup merge of rust-lang#152729 - Enselic:single_use_consts-not-requ…
62059cb 
…ired, r=cjgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang#107404 which was the precursor to `SingleUseConsts` (see rust-lang#125910 for the switch).
* By following the advice from rust-lang#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang#151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks rust-lang#151426.
jhpratt added a commit to jhpratt/rust that referenced this pull request Feb 18, 2026
@jhpratt
Rollup merge of rust-lang#152729 - Enselic:single_use_consts-not-requ…
5cd5e7c 
…ired, r=cjgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang#107404 which was the precursor to `SingleUseConsts` (see rust-lang#125910 for the switch).
* By following the advice from rust-lang#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang#151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks rust-lang#151426.
Zalathar added a commit to Zalathar/rust that referenced this pull request Feb 18, 2026
@Zalathar
Rollup merge of rust-lang#152729 - Enselic:single_use_consts-not-requ…
dbc2193 
…ired, r=cjgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang#107404 which was the precursor to `SingleUseConsts` (see rust-lang#125910 for the switch).
* By following the advice from rust-lang#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang#151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks rust-lang#151426.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 18, 2026
@JonathanBrouwer
Rollup merge of rust-lang#152628 - Enselic:ptr-const-allocation, r=ji…
72f3d8a 
…eyouxu

tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
rust-timer added a commit that referenced this pull request Feb 18, 2026
@rust-timer
Unrolled build for #152729
f851be2 
Rollup merge of #152729 - Enselic:single_use_consts-not-required, r=cjgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR #107404 which was the precursor to `SingleUseConsts` (see #125910 for the switch).
* By following the advice from #128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in #151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks #151426.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 18, 2026
@JonathanBrouwer
Rollup merge of rust-lang#152628 - Enselic:ptr-const-allocation, r=ji…
3cb8617 
…eyouxu

tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 18, 2026
@JonathanBrouwer
Rollup merge of rust-lang#152628 - Enselic:ptr-const-allocation, r=ji…
78fac69 
…eyouxu

tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Feb 18, 2026
@JonathanBrouwer
Rollup merge of rust-lang#152628 - Enselic:ptr-const-allocation, r=ji…
1489a8e 
…eyouxu

tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Feb 19, 2026
@Zalathar
Rollup merge of #152729 - Enselic:single_use_consts-not-required, r=c…
c651357 
…jgillot

compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"

I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang/rust#107404 which was the precursor to `SingleUseConsts` (see rust-lang/rust#125910 for the switch).
* By following the advice from rust-lang/rust#128657 (comment) we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](https://github.com/rust-lang/rust/blob/0ee7d96253f92b15115c94a530db8b79cb341b15/compiler/rustc_mir_transform/src/pass_manager.rs#L98-L102) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang/rust#151426 which stops enabling it by default in non-optimized builds.

As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.

Unblocks rust-lang/rust#151426.
rust-timer added a commit that referenced this pull request Feb 19, 2026
@rust-timer
Unrolled build for #152628
48782f4 
Rollup merge of #152628 - Enselic:ptr-const-allocation, r=jieyouxu

tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from #151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
@Enselic
compiler: Require mir_opt_level > 1 for SingleUseConsts
b4c9355 
To make `tests/debuginfo/basic-stepping.rs` prevent further regressions
of issue 33013.
@Enselic Enselic force-pushed the single-use-consts-mir-opt-level branch from 9eabf52 to b4c9355 Compare February 19, 2026 17:49
@rustbot

This comment was marked as off-topic.

Sign in to view
@Enselic
Copy link
Member Author

Enselic commented Feb 19, 2026

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 19, 2026
@Enselic
Copy link
Member Author

Enselic commented Feb 21, 2026 •
edited
Loading

Current reviewer has not been very active lately:

$ git log --grep=r=matthewjasper --format=%cd --date=short | head -n 2
2025-10-28
2025-08-21

@rustbot reroll

@rustbot rustbot assigned jackh726 and unassigned matthewjasper Feb 21, 2026
@mati865
Copy link
Member

mati865 commented Feb 21, 2026

IIUC this pass is supposed to run in debug mode. Do we need debug info for the dead code? All the variables in question are never used.

Cc @scottmcm

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Feb 22, 2026
@JonathanBrouwer
Rollup merge of #152628 - Enselic:ptr-const-allocation, r=jieyouxu
ec01b9a 
tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)

In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:

    fn other_consts() {{
        let _max_u128 = u128::MAX;
        let _min_i128 = i128::MIN;
        let _max_i8 = i8::MAX;
        let _char = 'x';
        let _false = false;
        let _true = true;
        let _ptr = &BAR;
        let _null_ptr: *const u8 = NULL;
        let _tuple = TUPLE;
        let _char_id = const {{ type_id::<char>() }};
        let _bool_id = const {{ type_id::<bool>() }};
    }}

The current test only finds 10 out of 11 allocations. The constant allocation for

    let _ptr = &BAR;

is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.

Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.

Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](Enselic/rust@d7fffab#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from rust-lang/rust#151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
@scottmcm
Copy link
Member

scottmcm commented Feb 22, 2026

This was definitely intended to run in debug mode, because it improves debug-mode codegen by helping skip entire blocks based on the value of the constant.

100% agreed with marking it non-required, but it loses most of its value in mir-opt-level=2 since GVN and friends can do so much better.

@Enselic
Copy link
Member Author

Enselic commented Feb 23, 2026 •
edited
Loading

Thank you for clarifying the intention. I'm still confused though, because "debug mode" and "optimization level" are completely orthogonal.

In general it is preferred to debug without optimizations. With optimizations, execution jumps around in unpredictable and unintuitive ways. And variables tend to get optimized away, making it impossible/tricky to inspect their values as you step through code.

Sometimes programs are prohibitively slow without optimizations (like rustc itself), so users are forced to combine -O with -g.

But why would we want to apply (optional) optimizations when the user has not requested optimizations? If someone wants "debug info with basic optimizations" they would use -g -O1.

Maybe we can run SimpleUseConsts at -O1 and GVN and friends at -O2 and up? (Just a casual question. I have not investigated it in-depth.)

@mati865
Copy link
Member

mati865 commented Feb 23, 2026

r? codegen

@rustbot rustbot assigned saethlin and unassigned jackh726 Feb 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@saethlin saethlin

Labels

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.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@Enselic @rust-log-analyzer @rustbot @chenyukang @mati865 @scottmcm @saethlin @matthewjasper @jackh726