Run InstSimplify before UnreachablePropagation

[saethlin]

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

r? @ghost

[saethlin]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0b77e30 with merge 49d1f0a...

[bors]

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

[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);
-        _8 = &(*_6);
+        _8 = &(((*_1) as Err).0: E);
         _7 = <E as Clone>::clone(move _8) -> [return: bb5, unwind continue];
     }

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]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0da8676 with merge 66e8eb9...

[bors]

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

[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%)

[cjgillot]

Oh I see the problem. ReferencePropagation does this:

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

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]

☔ The latest upstream changes (presumably #122225) made this pull request unmergeable. Please resolve the merge conflicts.

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