Allow inlining of ensure_sufficient_stack()

[hkratz]

This functions is monomorphized a lot and allowing the compiler to inline it improves instructions count and max RSS significantly in my local tests.

[rust-highfive]

r? @estebank

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

[bjorn3]

It should already be inlinable due to being generic, but maybe stacker::maybe_grow is inlined first and then LLVM considers the resulting function too big to be inlined by default?

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 59536fb with merge a771d063e5e2bc102c8c9e1ec5674ed02904864c...

[bors]

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

[rust-timer]

Queued a771d063e5e2bc102c8c9e1ec5674ed02904864c with parent 9cdefd7, future comparison URL.

[rust-timer]

Finished benchmarking commit (a771d063e5e2bc102c8c9e1ec5674ed02904864c): comparison url.

Summary: This benchmark run shows 18 relevant improvements 🎉 to instruction counts.

• Average relevant improvement: -0.5%
• Largest improvement in instruction counts: -1.5% on incr-unchanged builds of clap-rs check

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[estebank]

@bors r+

[bors]

📌 Commit 59536fb has been approved by estebank

[bors]

⌛ Testing commit 59536fb with merge c1aa854...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank
Pushing c1aa854 to master...

[rust-timer]

Finished benchmarking commit (c1aa854): comparison url.

Summary: This benchmark run shows 3 relevant improvements 🎉 but 3 relevant regressions 😿 to instruction counts.

• Average relevant regression: 0.9%
• Average relevant improvement: -0.8%
• Largest improvement in instruction counts: -1.0% on incr-patched: add vec item builds of deep-vector opt
• Largest regression in instruction counts: 0.9% on incr-unchanged builds of ctfe-stress-4 check

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[hkratz]

The trial perf run was before the LLVM 14 merge. It seems that the inlining behavior has changed so this isolated change is a wash now.

I have more optimizations for stacker lined up in #94099.

[rylev]

Agree that the change is now a wash.

@rustbot label: +perf-regression-triaged