Remove the size of locals heuristic in MIR inlining

[saethlin]

This heuristic doesn't necessarily correlate to complexity of the MIR Body. In particular, a lot of straight-line code in MIR tends to never reuse a local, even though any optimizer would effectively reuse the storage or just put everything in registers. So it doesn't even necessarily make sense that this would be a stack size heuristic.

So... what happens if we just delete the heuristic? The benchmark suite improves significantly. Less heuristics better?

r? @cjgillot

[saethlin]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 173845c with merge cbbf8037a859939483a183c7ce46714fda36d37d...

[bors]

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

[rust-timer]

Finished benchmarking commit (cbbf8037a859939483a183c7ce46714fda36d37d): 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.2%, 0.8%]	6
Regressions ❌ (secondary)	0.8%	[0.2%, 3.1%]	17
Improvements ✅ (primary)	-0.7%	[-1.6%, -0.2%]	61
Improvements ✅ (secondary)	-0.9%	[-2.3%, -0.2%]	51
All ❌✅ (primary)	-0.6%	[-1.6%, 0.8%]	67

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.0%	[1.2%, 11.3%]	7
Regressions ❌ (secondary)	4.5%	[2.6%, 6.3%]	2
Improvements ✅ (primary)	-1.6%	[-2.9%, -0.6%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.9%	[-2.9%, 11.3%]	11

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)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-1.4%	[-3.7%, -0.7%]	15
Improvements ✅ (secondary)	-2.6%	[-3.2%, -1.8%]	10
All ❌✅ (primary)	-1.4%	[-3.7%, -0.7%]	15

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[scottmcm]

Wow, those results look great to me.

(I don't know why doc builds regressed on instructions -- maybe just that rlibs are bigger with more inlining? -- but overall they look ½-and-½ above and below for cycles, including the non-relevant ones, so my guess is that's fine since you didn't change anything about rustdoc directly.)

Spitballing in case someone objects: another possibility would be to count only the size of Abi::Aggregate temporaries, since the others frequently end up in registers anyway. That would avoid needlessly penalizing "look, it's a usize temporary that's used immediately", but still catch the "wait, that's a [u64; 25] keccak-p state; maybe that's worth counting".

[cjgillot]

Thanks @saethlin!

Besides instruction count, we have a regression on metadata and binary size for optimized builds. I think those are tolerable (+0.4% on binary size, +2% on crate metadata on average). The regression in bootstrap timings is a unfortunate, but not a reason not to land this PR.

@scottmcm I'm not even convinced that the size of aggregates matters. Those aggregates would end up on the stack either way, through an inlined call or a regular call. Inlining gives the possibility to emit a copy, so that's good to take.

@bors r+

[bors]

📌 Commit 173845c has been approved by cjgillot

It is now in the queue for this repository.

[bors]

⌛ Testing commit 173845c with merge 915aa06...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 915aa06 to master...

[saethlin]

One of the biggest inlining changes due to this PR in the standard library is that fmt::Arguments::new_const is now inlined into every panic path. That seems undesirable to me, but it seems like just a symptom of the fact that panic!("oh no") expands to code that touches string formatting. I don't have any actual data to go on for what caused the max RSS and artifact size regressions, but this seems likely.

So MIR opts aside, I'm going to see what I can do about that. I don't know how to validate my guess without implementing a fix for it, so this may not be very quick.

[rust-timer]

Finished benchmarking commit (915aa06): 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.9%	[0.3%, 2.7%]	9
Regressions ❌ (secondary)	1.9%	[0.3%, 7.9%]	34
Improvements ✅ (primary)	-0.6%	[-1.8%, -0.2%]	59
Improvements ✅ (secondary)	-0.8%	[-2.5%, -0.2%]	46
All ❌✅ (primary)	-0.4%	[-1.8%, 2.7%]	68

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)	5.2%	[2.1%, 8.2%]	4
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-1.7%	[-2.5%, -0.5%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[-2.5%, 8.2%]	11

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)	2.2%	[1.3%, 3.1%]	3
Improvements ✅ (primary)	-1.2%	[-1.8%, -0.5%]	7
Improvements ✅ (secondary)	-2.0%	[-2.5%, -1.5%]	4
All ❌✅ (primary)	-1.2%	[-1.8%, -0.5%]	7

[saethlin]

keccak + cranelift-codegen 🙃

[nnethercote]

Improvements outweigh regressions.

@rustbot label: +perf-regression-triaged

[mqudsi]

General regression blocking cmov generation in if blocks seems to bisect to this change, causing branchier code to be emitted. #125338.