MIR move elimination [1.5/6]: Ensure ZSTs are always initialized

[Amanieu]

Split off from #163335

The new MIR semantics from rust-lang/rfcs#3943 require that a local be initialized before it is used, since it only gains an allocation at that point. This means that ZSTs must be initialized before being read, even though the initialization is a no-op in codegen.

This PR addresses this in 2 ways:

• Adds missing ZST initializations in MIR shims and MIR intrinsic lowering.
• Restricts the RemoveZsts pass to only remove ZST assignments when the destination is indirect, since such places are required to already be allocated anyways. This is fine in practice since dead ZST assignments are later removed by DSE.

The last one also exposed a limitation in SimplifyMatch's handling of constant equality when checking if two match arms are equivalent: it was only checking for scalar constants and was not handling () unit constants, which resulted in a test regression. The pass has been fixed to handle any kind of ConstValue.

r? tmiasko

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[tmiasko]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: ddd9a7e (ddd9a7ecfa5c69a3f9af801bd95c308d8b298a87)
Base parent: 5ceaf66 (5ceaf6608eb354c2f5bbb3b8d974caa367dac81c)

[rust-timer]

Finished benchmarking commit (ddd9a7e): 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)	1.0%	[0.4%, 2.4%]	5
Regressions ❌ (secondary)	0.7%	[0.2%, 2.2%]	9
Improvements ✅ (primary)	-0.6%	[-1.7%, -0.2%]	31
Improvements ✅ (secondary)	-0.4%	[-0.8%, -0.2%]	4
All ❌✅ (primary)	-0.4%	[-1.7%, 2.4%]	36

Max RSS (memory usage)

Results (primary -0.6%, secondary -0.3%)

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

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.8%, 2.0%]	2
Regressions ❌ (secondary)	1.9%	[1.3%, 2.3%]	3
Improvements ✅ (primary)	-5.7%	[-5.7%, -5.7%]	1
Improvements ✅ (secondary)	-2.5%	[-2.7%, -2.2%]	3
All ❌✅ (primary)	-0.6%	[-5.7%, 2.0%]	3

Cycles

Results (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)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.4%, 0.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.9%, secondary 0.8%)

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

	mean	range	count
Regressions ❌ (primary)	2.4%	[0.5%, 12.6%]	7
Regressions ❌ (secondary)	6.6%	[0.5%, 12.6%]	2
Improvements ✅ (primary)	-2.5%	[-6.5%, -0.0%]	14
Improvements ✅ (secondary)	-3.0%	[-5.2%, -1.6%]	3
All ❌✅ (primary)	-0.9%	[-6.5%, 12.6%]	21

Bootstrap: 488.629s -> 489.137s (0.10%)
Artifact size: 406.21 MiB -> 406.48 MiB (0.07%)

[Amanieu]

I investigated the perf results: they are entirely due to different CGU partitioning. Retaining ZST assignments affects function size estimates. The actual ZST assignments never make it to LLVM codegen.

[Amanieu]

I'm not sure how to properly address this one: it seems to be very sensitive to the MIR inliner threshold. Adding a _0 = () causes it to no longer inline, which fails the test. I can bypass that by raising the threshold from 50 to 52, but this feels like the wrong solution here.

View changes since the review

[dianqk]

We can treat _0 = () as a zero-cost statement in the inliner, since it's a no-op.

[Amanieu]

I'm happy to do that, but I'm just not sure whether special-casing this is the correct approach. We could alternatively just raise the default threshold by 5.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.