Remove some #[inline(always)]

[Noratrieb]

These are probably not necessary as the function bodies are trivial, so LLVM should inline them.

r? @compiler-errors as you told me to open the pr and want to start the perf run

[compiler-errors]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 22cb380 with merge b1c6494aa93caf777881ae15c6fa699693c247bd...

[bors]

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

[rust-timer]

Finished benchmarking commit (b1c6494aa93caf777881ae15c6fa699693c247bd): comparison URL.

Overall result: ❌ regressions - 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-review -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[1.0%, 1.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

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.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	8.4%	[8.4%, 8.4%]	1
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	0.1%	[-0.4%, 0.6%]	2

Cycles

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

[compiler-errors]

Hm, doesn't look like it's worth (just noise), so I'd probably leave 'em as is.

[saethlin]

Honestly with a significance factor of 1.08, I would do the perf run again and see if what the results look like. If it still regresses, try #[inline].

[saethlin]

I think we could use include to select just deeply-nested-multi, if we want. Maybe with iterations=10 or something like that. I think the default is 1?

[Kobzol]

Perf looks neutral to me, which is a good result here I suppose. Hopefully it's because of LTO kicking in.

[cjgillot]

As these functions are defined in rustc_query_impl, MIR inlining can pick them up.
I'm moving this file in rustc_middle with #103808.
Defined in another crate, MIR inlining have access to them unless there they are marked #[inline].

[Noratrieb]

Ah, I didn't notice that PR, with that it doesn't make sense and only causes conflicts. I guess they can still be changed from #[inline(always)] to #[inline] but that doesn't matter too much