(do not merge) Try some inline things with a skipped test

[tgross35]

arcinner_layout_for_value_layout is not currently being inlined, and we can't inline it since it is required by a test. Once figuring out how to rewrite the test we should be able to change this if the performance is worth it.

Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Inline.20causing.20failed.20codegen.20test

[rustbot]

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit b24b382 with merge 6e9848822c888a2f47242ff3f527ad23016db6ac...

[bors]

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

[bors]

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

[Noratrieb]

oops, misclicked the comment box. I hope I didn't cancel the try and perf builds. It's still in the perf queue so that looks good

What I wanted to say is that try builds don't require tests to pass, they don't test anything

[rust-timer]

Finished benchmarking commit (6e9848822c888a2f47242ff3f527ad23016db6ac): comparison URL.

Overall result: ✅ improvements - 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-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)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
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
Regressions ❌ (secondary)	1.9%	[1.1%, 3.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

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

Binary size

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.3%	[0.3%, 0.3%]	10
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.0%]	4
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-0.1%, 0.3%]	14

Bootstrap: 647.584s -> 648.501s (0.14%)

[tgross35]

Eh, that’s not very exciting. Can probably forget about this one

[Noratrieb]

do you mean that the inline is not worth it? I don't think the compiler allocates that many arcs, it mostly uses Rc so the benchmarks are not representative

[tgross35]

I guess I don't know in that case since I was assuming it's moreso Arc. Rc has a similar rcbox_layout_for_value_layout that I was able to inline here #113156, I guess that might be a contributor to the perf wins in that PR. Also means that RC might not have the regression test for #111603 like Arc does? (the one I disabled here).

If you know a way to fix that test so it's not just counting the function call, I can do that and add the inline as part of #113156. And probably do the same thing for Rc so it's getting tested. I just am not sure how to fix that test