Run InstSimplify before UnreachablePropagation by saethlin · Pull Request #123256 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation19 Commits1 Checks11 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

saethlin

@rustbot 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 31, 2024

@saethlin

@rust-timer

This comment has been minimized.

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 31, 2024

@bors

Run InstSimplify before UnreachablePropagation

This is the pass ordering change I was musing about: rust-lang#122975 (comment)

r? @ghost

@bors

@rust-log-analyzer

This comment has been minimized.

@bors

☀️ Try build successful - checks-actions
Build commit: 49d1f0a (49d1f0a7f4d467843f95684ca0eb51bca6cce28d)

@rust-timer

This comment has been minimized.

@rust-timer

Finished benchmarking commit (49d1f0a): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 1.0% [0.5%, 1.6%] 4
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -0.5% [-1.0%, -0.3%] 16
Improvements ✅ (secondary) -0.5% [-1.0%, -0.2%] 9
All ❌✅ (primary) -0.2% [-1.0%, 1.6%] 20

Max RSS (memory usage)

Results

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) 8.5% [2.2%, 19.1%] 3
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -2.8% [-5.0%, -0.0%] 4
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) 2.1% [-5.0%, 19.1%] 7

Cycles

Results

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) 1.2% [1.0%, 1.4%] 2
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) -3.7% [-4.5%, -2.9%] 2
All ❌✅ (primary) 1.2% [1.0%, 1.4%] 2

Binary size

Results

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.1% [0.0%, 0.7%] 35
Regressions ❌ (secondary) 0.0% [0.0%, 0.0%] 4
Improvements ✅ (primary) -0.4% [-1.1%, -0.0%] 50
Improvements ✅ (secondary) -0.6% [-1.3%, -0.1%] 25
All ❌✅ (primary) -0.2% [-1.1%, 0.7%] 85

Bootstrap: 670.332s -> 671.609s (0.19%)
Artifact size: 315.71 MiB -> 315.67 MiB (-0.01%)

@saethlin

The optimized MIR for Result::clone changes from this:

    bb2: {
        StorageLive(_6);
        _6 = &(((*_1) as Err).0: E);
        StorageLive(_7);
        StorageLive(_8);
        _8 = &(((*_1) as Err).0: E);
        _7 = <E as clone::Clone>::clone(move _8) -> [return: bb5, unwind continue];
    }

To this:

    bb2: {
        _5 = &(((*_1) as Err).0: E);
        StorageLive(_6); 
        _6 = <E as clone::Clone>::clone(move _5) -> [return: bb5, unwind continue];
    }

That is very surprising to me.

@saethlin

Oh I see the problem. ReferencePropagation does this:

     _6 = &(((*_1) as Err).0: E);
     StorageLive(_7);
     StorageLive(_8);

Then _6 is unused, but it has debuginfo, so SimplifyLocals won't remove it.

But if we move InstCombine before ReferencePropagation, InstCombine gets to see the reborrow and turns it into an assignment. Then SimplifyLocals considers optimizing out _8 instead of _6, which it can, because _8 has not debuginfo.

@cjgillot I only see this pattern crop up twice in core, but it seems worth doing something about. Do you think it's possible to get ReferencePropagation to behave the way we want here?

@saethlin

@rust-timer

This comment has been minimized.

@bors

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 31, 2024

@bors

Run InstSimplify before UnreachablePropagation

This is the pass ordering change I was musing about: rust-lang#122975 (comment)

r? @ghost

@rust-log-analyzer

This comment has been minimized.

@bors

☀️ Try build successful - checks-actions
Build commit: 66e8eb9 (66e8eb98489e088d62233c3026e6ae02f3ad6f04)

@rust-timer

This comment has been minimized.

@rust-timer

Finished benchmarking commit (66e8eb9): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 0.9% [0.4%, 1.6%] 5
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -0.5% [-0.8%, -0.2%] 15
Improvements ✅ (secondary) -0.4% [-0.6%, -0.2%] 9
All ❌✅ (primary) -0.1% [-0.8%, 1.6%] 20

Max RSS (memory usage)

Results

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) 2.6% [0.7%, 4.4%] 4
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -3.3% [-3.9%, -2.7%] 2
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) 0.6% [-3.9%, 4.4%] 6

Cycles

Results

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) 1.0% [0.7%, 1.4%] 3
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) -2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) 1.0% [0.7%, 1.4%] 3

Binary size

Results

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.1% [0.0%, 0.7%] 39
Regressions ❌ (secondary) 0.0% [0.0%, 0.0%] 4
Improvements ✅ (primary) -0.4% [-1.1%, -0.0%] 48
Improvements ✅ (secondary) -0.6% [-1.4%, -0.1%] 25
All ❌✅ (primary) -0.2% [-1.1%, 0.7%] 87

Bootstrap: 668.134s -> 670.326s (0.33%)
Artifact size: 315.67 MiB -> 315.67 MiB (0.00%)

@saethlin

@cjgillot

Oh I see the problem. ReferencePropagation does this:

    _6 = &(((*_1) as Err).0: E);
    StorageLive(_7);
    StorageLive(_8);

Then _6 is unused, but it has debuginfo, so SimplifyLocals won't remove it.

But if we move InstCombine before ReferencePropagation, InstCombine gets to see the reborrow and turns it into an assignment. Then SimplifyLocals considers optimizing out _8 instead of _6, which it can, because _8 has not debuginfo.

@cjgillot I only see this pattern crop up twice in core, but it seems worth doing something about. Do you think it's possible to get ReferencePropagation to behave the way we want here?

Reference propagation could absolutely do that transform. We'd lose some information about reborrows, but none we actually use, so that's OK.

@bors

@saethlin

I'm going to close this because I think the right action here is to not do what I was envisioning, but to improve ReferencePropagation.