GVN: transmute adts to their fields if a field projection is immediately transmuted anyway

[oli-obk]

follow-up to #152702

commits best reviewed individually.

Basically does

-         _11 = copy ((_10.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>) as *const () (Transmute);
+         _11 = copy _10 as *const () (Transmute);

in various forms, including going from an Option directly to a value in its Some variant if the value got niche optimized into the Option

r? @scottmcm
cc @cjgillot

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: de634ba (de634ba015f8ccb17717cd0fbd048e381b7e297c, parent: 58745ca3b05afa82bd5720dd05f3854e674700e0)

[rust-timer]

Finished benchmarking commit (de634ba): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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)	0.3%	[0.1%, 0.4%]	3
Improvements ✅ (primary)	-0.3%	[-0.8%, -0.2%]	8
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.2%]	6
All ❌✅ (primary)	-0.1%	[-0.8%, 0.8%]	10

Max RSS (memory usage)

Results (primary 5.3%, secondary 6.8%)

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

	mean	range	count
Regressions ❌ (primary)	5.3%	[2.1%, 13.0%]	4
Regressions ❌ (secondary)	6.8%	[5.4%, 8.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	5.3%	[2.1%, 13.0%]	4

Cycles

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

Binary size

Results (primary -0.1%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 0.5%]	5
Regressions ❌ (secondary)	0.3%	[0.0%, 0.5%]	8
Improvements ✅ (primary)	-0.5%	[-1.2%, -0.0%]	4
Improvements ✅ (secondary)	-0.3%	[-0.7%, -0.0%]	5
All ❌✅ (primary)	-0.1%	[-1.2%, 0.5%]	9

Bootstrap: 478.569s -> 481.658s (0.65%)
Artifact size: 395.75 MiB -> 397.78 MiB (0.51%)

[cjgillot]

Should this be another VariantIdx if field_value is a downcast?

[cjgillot]

Suggested change

	&& let Ok(projected_layout) = self.ecx.layout_of(self.ty(value))
	&& let Ok(projected_layout) = self.ecx.layout_of(from)

[scottmcm]

Very cool! I like that we can do this in mir so it can handle things like Box<T> -> *mut T directly that we couldn't do in the library because of needing to work with non-ZST Allocators. I skimmed through some of the test updates and those all seem fine. Plus lovely to see check & debug improvements from a pass that doesn't even run in debug :)

I really don't feel confident that I know the nuances of GVN enough to comfortable reviewing this, though, so
r? cjgillot

[dianqk]

regression?

[scottmcm]

Hmm, it means we didn't know the NonNull-ness before, and we don't (currently) elide transmutes like this when the middle type is more specific than the source or destination in order to preserve that extra niche information for the backend.

See discussion in #152702 (comment) ; I don't think doing something about it needs to be this PR.

[scottmcm]

Opened #153251 to get rid of the extra step here.