Reduce MIR cost penalty for asserts and diverging calls to improve inlining of safety-checked functions

[stephenduong1004]

View all comments

Implicit Rust safety checks (arithmetic overflow, bounds checks) generate Assert terminators and diverging Calls (panics) in MIR. Currently, the MIR inliner penalizes these as expensive function calls.

This creates a Catch-22: the compiler blocks inlining because the safety checks make the function look too large, but inlining is what is required to prove those checks are unreachable and optimize them away. This penalizes small, hot functions containing safety checks.

This PR modify CostChecker in cost_checker.rs to:

Charge TerminatorKind::Assert as a standard instruction instead of a full call.
Charge diverging TerminatorKind::Calls (panic paths) as INSTR_COST = 5.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

r? @JonathanBrouwer

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, mir, mir-opt
• compiler, mir, mir-opt expanded to 74 candidates
• Random selection from 18 candidates

[stephenduong1004]

@bors try @rust-timer queue

[rust-bors]

@stephenduong1004: 🔑 Insufficient privileges: not in try users

[hanna-kruppe]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: ac10c6b (ac10c6bef2fe63b6a18e79ff83e6f11c1772e583)
Base parent: 9e71b3b (9e71b3bc704eea68d39bd0f6a46703c7d22f5d3b)

[rust-timer]

Finished benchmarking commit (ac10c6b): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 0.8%]	2
Regressions ❌ (secondary)	1.0%	[0.2%, 1.9%]	15
Improvements ✅ (primary)	-0.4%	[-0.6%, -0.2%]	3
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-0.0%	[-0.6%, 0.8%]	5

Max RSS (memory usage)

Results (primary 1.7%, secondary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	4.0%	[2.1%, 5.8%]	2
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-4.7%	[-5.2%, -4.2%]	2
All ❌✅ (primary)	1.7%	[-2.8%, 5.8%]	3

Cycles

Results (secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.7%	[3.2%, 4.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.3%, secondary 0.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.6%	[0.1%, 4.9%]	7
Regressions ❌ (secondary)	0.7%	[0.1%, 4.9%]	12
Improvements ✅ (primary)	-0.2%	[-1.3%, -0.0%]	19
Improvements ✅ (secondary)	-0.1%	[-0.3%, -0.0%]	8
All ❌✅ (primary)	0.3%	[-1.3%, 4.9%]	26

Bootstrap: 486.168s -> 486.162s (-0.00%)
Artifact size: 392.47 MiB -> 391.75 MiB (-0.19%)

[stephenduong1004]

Hi @JonathanBrouwer,

The perf results align with what I had in mind. It seems the previous MIR inliner cost model was too conservative.

While the more aggressive inlining causes compile time to increase, both the reduction in runtime and compiler/binary sizes show that the additional inlining is still beneficial.

I am very new to the Rust compiler community, so I would love to get your feedback and ideas on a few things:

• How does the community typically weigh compile-time regressions against runtime speedups and binary size reductions?
• Are there specific performance limits or thresholds I should be aware of?
• Should we look into making the cost model even more aggressive or conservative comparing to this?

Thanks in advance for your guidance!

[panstromek]

Note that some of the regressed builds are check and debug builds, which don't run MIR inliner. This means that this is also a runtime regression in some cases, when applied to the compiler itself. This doesn't preclude us from landing it, but it would be nice to know why that happens and whether we can do something about it.

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: b66603c (b66603c26f8be3f304f0ae19cfe8a0fa030f7d78)
Base parent: 87e5904 (87e5904f5eb6398af6b22eac2802c78934260c48)

[rust-timer]

Finished benchmarking commit (b66603c): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	1

Max RSS (memory usage)

Results (secondary -1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-2.3%, -0.9%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -4.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.9%, -3.0%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%, secondary -0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.1%, 0.9%]	2
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-0.1%	[-0.5%, -0.0%]	5
Improvements ✅ (secondary)	-0.5%	[-0.5%, -0.5%]	1
All ❌✅ (primary)	0.0%	[-0.5%, 0.9%]	7

Bootstrap: 486.983s -> 487.999s (0.21%)
Artifact size: 391.82 MiB -> 392.46 MiB (0.17%)