Have the alignment intrinsics return ptr::Alignment directly

[scottmcm]

Follow-up to #152605

Notably, a common case of align_of_val is to put it in Layout for allocator calls, so might as well have it just be an Alignment already to avoid the extra transmute.

No changes to rustc_const_eval because that's already writing a Scalar into a place, which does what we need since ptr::Alignment is repr(transparent) to a repr(usize).

[scottmcm]

We didn't have a test for the alignment checks, it seems, so the first commit adds one.

[scottmcm]

This transmute no longer being needed is perhaps the clearest demo of this PR.

[scottmcm]

I don't think anything in here should be more expensive, but in case...
@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 7121e2d (7121e2d136c08d87b9a5f3717916d4bec53334bb, parent: 2219766af622ad1f051ca96ae40650106b1bd9bd)

[rust-timer]

Finished benchmarking commit (7121e2d): 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)	4.5%	[0.2%, 16.2%]	4
Regressions ❌ (secondary)	0.6%	[0.3%, 0.9%]	2
Improvements ✅ (primary)	-0.4%	[-1.2%, -0.2%]	7
Improvements ✅ (secondary)	-1.0%	[-3.3%, -0.1%]	22
All ❌✅ (primary)	1.4%	[-1.2%, 16.2%]	11

Max RSS (memory usage)

Results (primary -3.9%, secondary 2.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)	5.2%	[1.3%, 9.0%]	2
Improvements ✅ (primary)	-3.9%	[-5.4%, -1.6%]	5
Improvements ✅ (secondary)	-1.7%	[-1.7%, -1.7%]	1
All ❌✅ (primary)	-3.9%	[-5.4%, -1.6%]	5

Cycles

Results (primary 11.9%, 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)	11.9%	[11.9%, 11.9%]	1
Regressions ❌ (secondary)	4.0%	[4.0%, 4.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-4.8%, -2.2%]	4
All ❌✅ (primary)	11.9%	[11.9%, 11.9%]	1

Binary size

Results (primary 0.3%, 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)	0.6%	[0.0%, 1.4%]	14
Regressions ❌ (secondary)	0.2%	[0.0%, 0.4%]	8
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.1%]	4
Improvements ✅ (secondary)	-1.3%	[-2.2%, -0.4%]	17
All ❌✅ (primary)	0.3%	[-0.7%, 1.4%]	18

Bootstrap: 485.129s -> 482.811s (-0.48%)
Artifact size: 398.01 MiB -> 396.01 MiB (-0.50%)

[scottmcm]

r? @cjgillot
@rustbot ready

Those perf results are, I think, overall good. They're mostly green, and include things like -28% on rustc_mir_build, which is impressively good.

The one big regression is one of the LTO sub-jobs just going nuts for some reason:

TBH I'm not sure how this could possibly cause that. It's not the kind of "oh, inlining reshuffled everything" that we normally see from MIR changes. None of the other variants of that code show any material impact, and it's just so different from the results on everything else.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

This PR modifies tests/auxiliary/minicore.rs.

cc @jieyouxu

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[saethlin]

TBH I'm not sure how this could possibly cause that

The magnitude is indeed surprising, but squinting at the query execution changes, I do see that there are two more metadata_decode_entry_optimized_mir, so I wonder if the change here pushes some common API over the threshold to become cross-crate-inlinable and that one CGU explodes.

I'd build the benchmark before and after and ar x the rlbs then ls -lS *.o and see if something jumps out. Or look at -Zdump-mono-stats.

[cjgillot]

IIUC, this PR does two things:

• gets rid of SizedTypeProperties::ALIGN, to only use SizedTypeProperties::ALIGNMENT;
• change the return types of align intrinsics.

Do you have an idea which changes causes the perf improvements?
And why/how cranelift-codegen-0.119.0-Opt-Full regresses?

[scottmcm]

IIUC, this PR does two things:

TBH I hadn't been planning to go quite as far in one PR, but things ended up more conflated than I'd originally expected because of things like the align_of_val::<[T]> → T::ALIGN mir-opt. (For example, I originally was only going to change align_of_val, since that's the only one that doesn't const-prop out, but the mir-opt meant that it felt nicer to change align_of too.)

I guess I could try adding LangItem::AlignmentOf and doing a smaller change -- maybe it'd be basically just the exchange_malloc? -- and see how that lands. Would remove the need to tweak the alignment checks and such (not that those are on for opt-full that had the regression).

[rust-bors]

☔ The latest upstream changes (presumably #148190) made this pull request unmergeable. Please resolve the merge conflicts.