Tentatively inline(always) the trivial Into::into

[SoniEx2]

#100733 looked exciting, maybe this also does something.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[the8472]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit df0ffa3705c164b43832a5fd660f9699c6431836 with merge 50176d3628c97ec5a756307cb74225a71518cdb4...

[bors]

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

[rust-timer]

Queued 50176d3628c97ec5a756307cb74225a71518cdb4 with parent 57ee5cf, future comparison URL.

[rust-timer]

Finished benchmarking commit (50176d3628c97ec5a756307cb74225a71518cdb4): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@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.

	mean1	range	count2
Regressions ❌ (primary)	0.6%	[0.5%, 0.8%]	7
Regressions ❌ (secondary)	1.3%	[1.3%, 1.3%]	2
Improvements ✅ (primary)	-0.7%	[-1.4%, -0.3%]	24
Improvements ✅ (secondary)	-0.9%	[-1.6%, -0.3%]	35
All ❌✅ (primary)	-0.4%	[-1.4%, 0.8%]	31

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.

	mean1	range	count2
Regressions ❌ (primary)	9.8%	[9.8%, 9.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.6%	[-2.9%, -2.3%]	2
Improvements ✅ (secondary)	-3.2%	[-3.7%, -2.1%]	5
All ❌✅ (primary)	1.5%	[-2.9%, 9.8%]	3

Cycles

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

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²

[SoniEx2]

actually after some discussion it seems this should not be done, because #[inline(always)] is bottom-up. some folks suggested adding a pass which can inline these trivial forwarding functions instead. tho huh, really didn't expect those results.

[scottmcm]

Consider trying this with just #[inline] instead of #[inline(always)]. That might let LLVM use its heuristics to avoid the more painful cases here.

[SoniEx2]

we can try... but ideally this would inline as much as the underlying From, which is only possible if there was a pass to forward these kinds of functions... (then an #[inline(always)] in a From would automatically benefit the relevant Into.)

[scottmcm]

Re-perfing without the always

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit f197ac9 with merge 6ebe066db9f7ac6202dcae347319d205be8ab18e...

[bors]

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

[rust-timer]

Queued 6ebe066db9f7ac6202dcae347319d205be8ab18e with parent 90c34fa, future comparison URL.

[rust-timer]

Finished benchmarking commit (6ebe066db9f7ac6202dcae347319d205be8ab18e): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@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.

	mean1	range	count2
Regressions ❌ (primary)	0.6%	[0.5%, 0.8%]	7
Regressions ❌ (secondary)	1.3%	[1.3%, 1.3%]	2
Improvements ✅ (primary)	-0.6%	[-1.2%, -0.3%]	18
Improvements ✅ (secondary)	-1.0%	[-1.9%, -0.3%]	26
All ❌✅ (primary)	-0.3%	[-1.2%, 0.8%]	25

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.4%, -2.9%]	2
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.

	mean1	range	count2
Regressions ❌ (primary)	2.7%	[2.7%, 2.7%]	1
Regressions ❌ (secondary)	2.5%	[2.5%, 2.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	2.7%	[2.7%, 2.7%]	1

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[SoniEx2]

we wanna say that looks worse tho we're not good at reading these. would be nice to have a proper top-down inlining pass so that #[inline] on From means more than nothing.

[memoryruins]

For similar concerns about inline(always) on into from a couple years ago, #74645 (comment), which contains an example of the bottom-up behavior greatly increasing code size.

[SoniEx2]

ugh, we wish we could somehow make the compiler simply "resolve" this Into::into impl as the corresponding From::from call. like alias fn into = fn from somehow. (that would work yeah? might make some weird error messages if it resolves to this impl, and also <U as Into<T>>::into == <T as From<U>>::from would be true... whether those things matter, we don't know.)

or like. anything that would make this easier to pull off.

[SoniEx2]

we'll be closing this for now we guess.

[nikic]

I think we should reopen this one (the #[inline] variant, not #[inline(always)]). The perf result was mostly positive, including on bootstrap timings. I believe we do want this from() wrapper to be instantiated in all CGUs, because in most cases the from() implementation is trivial as well, and this is important for looking through abstractions. into() shows up a lot in #102539 (comment).