Only enable ConstProp at mir-opt-level >= 2.

[cjgillot]

That pass is not responsible for lints any more, so we can restrict it to optimized builds.

This reduces the amount of duplicated const-eval messages.

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[cjgillot]

@bors try @rust-timer queue

[bors]

⌛ Trying commit e5fa186b67f621a6d2a57e358577d3ee768022f7 with merge 32a9fa12c38e5dfd03b2d1bbf3e585b088249631...

[bors]

☀️ Try build successful - checks-actions
Build commit: 32a9fa12c38e5dfd03b2d1bbf3e585b088249631 (32a9fa12c38e5dfd03b2d1bbf3e585b088249631)

[bors]

☀️ Try build successful - checks-actions
Build commit: 32a9fa12c38e5dfd03b2d1bbf3e585b088249631 (32a9fa12c38e5dfd03b2d1bbf3e585b088249631)

[saethlin]

I'm pretty sure this won't break this mir-opt test, but it should:

rust/tests/mir-opt/div_overflow.rs

Line 1 in cf7ada2

// compile-flags: -Copt-level=0 -Coverflow-checks=yes

I think it won't break it because the mir-opt tests all override -Zmir-opt-level=4, instead of basing the MIR opt level on -Copt-level, which is what this test is supposed to look for.

[rust-timer]

Finished benchmarking commit (32a9fa12c38e5dfd03b2d1bbf3e585b088249631): 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.5%	[0.4%, 0.9%]	6
Regressions ❌ (secondary)	27.3%	[23.9%, 29.6%]	3
Improvements ✅ (primary)	-0.8%	[-1.6%, -0.3%]	13
Improvements ✅ (secondary)	-1.0%	[-1.8%, -0.1%]	26
All ❌✅ (primary)	-0.4%	[-1.6%, 0.9%]	19

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)	4.6%	[0.2%, 9.0%]	2
Regressions ❌ (secondary)	33.7%	[1.0%, 76.7%]	5
Improvements ✅ (primary)	-2.5%	[-2.8%, -2.2%]	3
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	2
All ❌✅ (primary)	0.3%	[-2.8%, 9.0%]	5

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)	-	-	0
Regressions ❌ (secondary)	28.3%	[15.6%, 35.1%]	3
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-2.3%	[-2.4%, -2.2%]	3
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

[oli-obk]

So we lose some perf for hyper and keccak, but gain some across the board. The losses are entirely due to

• more LLVM codegen, as we generate more LLVM-IR
• more metadata encoding as we encode more MIR

This makes me wonder if the const prop PR is useful at all (so also in release mode) except to provide simpler MIR for other MIR opts?

[oli-obk]

I'm pretty sure this won't break this mir-opt test, but it should:

hmm... do you think this is an issue? I think the rest of the tests (ui tests) should suffice for testing the debug/release defaults.

[saethlin]

Yes, that is an issue. That mir-opt test is supposed to check that we don't emit a specific unreachable panic branch in debug mode, and after this PR we will again emit the undesirable panic. That test never tested what it was supposed to. It should have been a codegen test.

If you are deciding in this PR to regress our codegen in debug builds, we should reopen that issue. Maybe someone can find another way to get the desired codegen.

[oli-obk]

If you are deciding in this PR to regress our codegen in debug builds, we should reopen that issue. Maybe someone can find another way to get the desired codegen.

the relevant issue is #72751

While this PR regresses that issue, the issue had no motivation explicitly mentioned. As long as we were able to trivially support it, that seems like a no-brainer, but I don't see a strong reason for actually avoiding emitting the panic path in debug builds. If there is such a reason, we should of course do something about it, but I found none in the PRs or issues linked to or from #72751

[bors]

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

[oli-obk]

@bors r+

[bors]

📌 Commit 4a5c14877c0d8cdca2b3d0454616bac63b2efbf7 has been approved by oli-obk

It is now in the queue for this repository.

[cjgillot]

That failure is an existing bug in codegen which was hidden by const-prop 😭. Filed #110128 while I investigate a fix.

[cjgillot]

Blocked on #110197

[cjgillot]

@bors r=oli-obk

[bors]

📌 Commit 483525e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 483525e with merge 67e273b...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 67e273b to master...

[rust-timer]

Finished benchmarking commit (67e273b): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.6%	[0.3%, 1.0%]	8
Regressions ❌ (secondary)	13.9%	[0.2%, 29.6%]	6
Improvements ✅ (primary)	-0.7%	[-1.5%, -0.3%]	13
Improvements ✅ (secondary)	-1.1%	[-1.8%, -0.1%]	14
All ❌✅ (primary)	-0.2%	[-1.5%, 1.0%]	21

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.5%	[0.3%, 4.6%]	3
Regressions ❌ (secondary)	53.7%	[13.0%, 74.8%]	3
Improvements ✅ (primary)	-3.6%	[-4.5%, -2.6%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-4.5%, 4.6%]	5

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)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	27.1%	[15.7%, 33.1%]	3
Improvements ✅ (primary)	-1.3%	[-1.7%, -0.7%]	4
Improvements ✅ (secondary)	-1.5%	[-1.5%, -1.5%]	1
All ❌✅ (primary)	-0.6%	[-1.7%, 2.2%]	5