Extend the alignment check to borrows

[1c3t3a]

The current alignment check does not include checks for creating misaligned references from raw pointers, which is now added in this patch.

When inserting the check we need to be careful with references to field projections (e.g. &(*ptr).a), in which case the resulting reference must be aligned according to the field type and not the type of the pointer.

r? @saethlin

cc @RalfJung, after our discussion in #134424

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[RalfJung]

When inserting the check we need to be careful with references to field projections (e.g. &(*ptr).a), in which case the resulting reference must be aligned according to the field type and not the type of the pointer.

Yes, that is the most subtle part. Please add a test ensuring we do not complain in a case where ptr: *const Align8Struct, then we do &(*ptr.u8_field), and the ptr points to an odd address.

[1c3t3a]

We actually already have a test for this (@saethlin added an amazing test-suite for this check): https://github.com/rust-lang/rust/blob/2b285cd5f0877e30ad1d83e04f8cc46254e43391/tests/ui/mir/alignment/place_computation.rs. I rename it as part of this PR to make it more clear what we actually test here in the context of the new pass.

[saethlin]

@bors try @rust-timer queue

[bors]

⌛ Trying commit d3ef125 with merge a7ce54d...

[bors]

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

[rust-timer]

Finished benchmarking commit (a7ce54d): comparison URL.

Overall result: no relevant changes - no 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.

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

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.8%)

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.4%	[1.3%, 7.9%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.5%	[-2.7%, -2.4%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.8%	[-2.7%, 7.9%]	8

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.1%)

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.5%]	35
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.4%, -0.0%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.4%, 0.5%]	41

Bootstrap: 782.898s -> 782.134s (-0.10%)
Artifact size: 365.21 MiB -> 365.22 MiB (0.00%)

[1c3t3a]

The perf results look good I think, especially compared to the added null-check. What do you think @saethlin, @RalfJung?