Always inline InterpCx::layout_of after perf regression

[Stypox]

Followup to #142721 to fix the performance regression. I ran one quick benchmark locally (ctfe-stress-5) and it does seem to be faster. I further tried adding #[inline(always)] to compiler/rustc_middle/src/ty/layout.rs in layout_of() under LayoutOfHelpers but that didn't change the benchmark results at all.

@rust-timer build e7e3c9e

(I'm not sure I have permission to do the above)

r? @RalfJung

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[RalfJung]

That's not quite the right command -- and indeed you won't have permission.

@bors2 try
@rust-timer-queue

[rust-bors]

⌛ Trying commit e7e3c9e with merge 1ab17c0…

To cancel the try build, run the command @bors2 try cancel.

[RalfJung]

Argh...
@rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1ab17c0 (1ab17c02e0da006756c695942d5aaceaf2bb9a39, parent: b94bd12401d26ccf1c3b04ceb4e950b0ff7c8d29)

[rust-timer]

Finished benchmarking commit (1ab17c0): comparison URL.

Overall result: ❌ regressions - no action needed

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.

@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
Regressions ❌ (secondary)	1.8%	[0.1%, 2.3%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.3%, secondary 1.4%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	1.4%	[0.4%, 2.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.3%	[2.3%, 2.3%]	1

Cycles

Results (primary -0.6%, secondary 0.9%)

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

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.4%, 1.9%]	2
Regressions ❌ (secondary)	1.6%	[0.5%, 2.6%]	2
Improvements ✅ (primary)	-5.0%	[-5.0%, -5.0%]	1
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	-0.6%	[-5.0%, 1.9%]	3

Binary size

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

Bootstrap: 462.452s -> 461.112s (-0.29%)
Artifact size: 372.20 MiB -> 372.36 MiB (0.04%)

[RalfJung]

So, uh, somehow this actually makes things even worse...?

[RalfJung]

It seems potentially non-trivial to optimize away the drop glue for this _span variable for the CTFE instance of the machine. I wonder if it would help to make that analysis easier for the compiler: instead of a TRACING_ENABLED associated constant, we could have:

type ENTERED_TRACING_SPAN = ();
fn enter_tracing_span(tracing::Span) -> Self::ENTERED_TRACING_SPAN { () }

The macro then simply expands to $machine::enter_tracing_span(tracing::info_span!($($tt)*)).