Add #[rustc_no_mir_inline] for standard library UB checks

[Noratrieb]

should help with #121110 and also with #120848

Because the MIR inliner cannot know whether the checks are enabled or not, so inlining is an unnecessary compile time pessimization when debug assertions are disabled. LLVM knows whether they are enabled or not, so it can optimize accordingly without wasting time.

r? @saethlin

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[saethlin]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 749d7e2 with merge 90741d3...

[bors]

☀️ Try build successful - checks-actions
Build commit: 90741d3 (90741d31a5aa2901d7f92a68a87c1ff5a32b3afa)

[rust-timer]

Finished benchmarking commit (90741d3): comparison URL.

Overall result: ❌ regressions - 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.6%	[0.2%, 1.3%]	16
Regressions ❌ (secondary)	2.6%	[0.5%, 5.3%]	8
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[-0.3%, 1.3%]	17

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)	1.8%	[0.7%, 2.6%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-6.0%	[-18.2%, -1.1%]	4
Improvements ✅ (secondary)	-5.4%	[-5.4%, -5.4%]	1
All ❌✅ (primary)	-2.7%	[-18.2%, 2.6%]	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.4%	[1.3%, 1.6%]	2
Regressions ❌ (secondary)	3.7%	[2.4%, 6.0%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.4%	[1.3%, 1.6%]	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.6%	[0.0%, 2.2%]	71
Regressions ❌ (secondary)	2.2%	[0.0%, 4.3%]	18
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.0%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[-0.3%, 2.2%]	77

Bootstrap: 636.575s -> 636.125s (-0.07%)
Artifact size: 306.16 MiB -> 306.10 MiB (-0.02%)

[saethlin]

Usually what I do at this point is look at the LLVM IR that's generated for the most-regressed case and see which precondition check dominates.

Generally I suspect slice::from_raw_parts. That function and its _mut version are used all over and the actual check implementation is about twice as big as it needs to be I think because the current implementation handles the case of invalid alignment. So assuming that it's slice::from_raw_parts I have two ideas:

• Write the slice::from_raw_parts precondition in a way that dodges the extra code; ptr::is_aligned_to incurs checking from Alignment::new, and ptr.addr() % alignment incurs a check for alignment == 0. Just doing & (align - 1) == 0 is probably appropriate here?
• Replace the use of that function in Vec::deref with &* ptr::slice_from_raw_parts. The precondition check in there should be redundant anyway, unless someone manages to smuggle an invalid Vec via transmute.

We should probably do both eventually on their own merits, but it might be useful to perf them separately.

[scottmcm]

I'd love to have #[rustc_no_mir_inline], regardless of whether using it in these specific cases here ends up working.

For example, in

rust/library/core/src/slice/mod.rs

Lines 979 to 985 in c1b478e

	// Introducing a function boundary here means that the two halves
	// get `noalias` markers, allowing better optimization as LLVM
	// knows that they're disjoint, unlike in the original slice.
	revswap(front_half, back_half, half_len);
	#[inline]
	fn revswap<T>(a: &mut [T], b: &mut [T], n: usize) {

it's very useful to preserve the function boundary for LLVM to see noalias, thus mir-inlining it is counter-productive, but it's also important that it be #[inline] especially when it's called on arrays.

[Noratrieb]

I need to write down why this is a good idea and necessary but to remind myself: the reason is that mir inlining doesn't see through debug_assertions.

[Noratrieb]

I think we should merge this despite the regressions and count the regressions as part of this unsafe precondition checking and work on that instead of blocking this PR which is a significant improvement for users.
trying out removing the check from vec deref anyways (though thats probably more significant for runtime than compile time)
@bors try @rust-timer queue

[saethlin]

In addition to that, we should recoup some of these regressions by improving our lowering of if false and if true: #120650 #121421

Can you add a mir-opt test that demonstrates that this prevents MIR inlining?

[Noratrieb]

I have added a test, and confirmed that the test fails properly when removing the attribute from the callee (never trust a test you didn't see fail etc etc).

[saethlin]

@bors r+

[bors]

📌 Commit 7e10cc5 has been approved by saethlin

It is now in the queue for this repository.

[Noratrieb]

fuck
@bors r-

[Noratrieb]

@bors r=saethlin

[bors]

📌 Commit 81d7069 has been approved by saethlin

It is now in the queue for this repository.

[bors]

⌛ Testing commit 81d7069 with merge e9f9594...

[bors]

☀️ Test successful - checks-actions
Approved by: saethlin
Pushing e9f9594 to master...

[rust-timer]

Finished benchmarking commit (e9f9594): 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.5%	[0.2%, 1.2%]	33
Regressions ❌ (secondary)	1.5%	[0.3%, 5.5%]	12
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	3
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.2%]	8
All ❌✅ (primary)	0.4%	[-0.3%, 1.2%]	36

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.7%	[0.9%, 4.5%]	5
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-9.5%	[-13.2%, -5.8%]	2
Improvements ✅ (secondary)	-4.5%	[-6.3%, -1.1%]	4
All ❌✅ (primary)	-0.8%	[-13.2%, 4.5%]	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.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	3.6%	[2.5%, 6.2%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	1.0%	[1.0%, 1.0%]	1

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.7%	[0.1%, 2.3%]	61
Regressions ❌ (secondary)	2.1%	[0.1%, 4.4%]	18
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	15
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[-0.2%, 2.3%]	76

Bootstrap: 651.95s -> 651.212s (-0.11%)
Artifact size: 311.05 MiB -> 311.01 MiB (-0.01%)

[Noratrieb]

That's more regressions than the previous check showed. Still, my previous analysis should apply. #121421 should get some of it back as well

[apiraino]

fixes #121245