Adjust inlining attributes around panic_immediate_abort

[saethlin]

The goal of panic_immediate_abort is to permit the panic runtime and formatting code paths to be optimized away. But while poking through some disassembly of a small program compiled with that option, I found that was not the case. Enabling LTO did address that specific issue, but enabling LTO is a steep price to pay for this feature doing its job.

This PR fixes that, by tweaking two things:

• All the slice indexing functions that we const_eval_select on get #[inline]. objdump -dC told me that originally some _ct functions could end up in an executable. I won't pretend to understand what's going on there.
• Normalize attributes across all panic! wrappers: use inline(never) + cold normally, and inline when panic_immediate_abort is enabled.

But also, with LTO and panic_immediate_abort enabled, this patch knocks ~709 kB out of the .text segment of librustc_driver.so. That is slightly surprising to me, my best theory is that this shifts some inlining earlier in compilation, enabling some subsequent optimizations. The size improvement of librustc_driver.so with panic_immediate_abort due to this patch is greater with LTO than without LTO, which I suppose backs up this theory.

I do not know how to test this. I would quite like to, because I think what this is solving was an accidental regression. This only works with -Zbuild-std which is a cargo flag, and thus can't be used in a rustc codegen test.

r? @thomcc

---

I do not seriously think anyone is going to use a compiler built with panic_immediate_abort, but I wanted a big complicated Rust program to try this out on, and the compiler is such.

[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

[thomcc]

I don't think we want to change runtime things for the non-panic_immediate_abort case.

[saethlin]

Based on some of your prompting elsewhere I think I have found other opportunities for tweaks along these lines. I want to run those down then decide if they belong in here.

[thomcc]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 5b0baa9614a34329e90f08b8f70a5df86425be45 with merge 17e1dcef1c425dbbe0e2f0d4f6f1fcf962d1cc90...

[bors]

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

[rust-timer]

Finished benchmarking commit (17e1dcef1c425dbbe0e2f0d4f6f1fcf962d1cc90): comparison URL.

Overall result: no relevant changes - 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 benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

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

Cycles

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

[saethlin]

@rustbot ready

[thomcc]

LGTM, thanks.

@bors r+

[bors]

📌 Commit 906c360 has been approved by thomcc

It is now in the queue for this repository.

[bors]

⌛ Testing commit 906c360 with merge 96c520d2784be83c65edcec5d87bb5dde74b1a6e...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

.......... (80/90)
.......... (90/90)


/checkout/src/test/rustdoc-gui/basic-code.goml basic-code... FAILED
[ERROR] (line 3) Error: Execution context was destroyed, most likely because of a navigation.: for command `assert-count: (".src-line-numbers", 1)`
Build completed unsuccessfully in 0:02:19

[saethlin]

@thomcc The failure looks like some kind of network-related flake to me? Maybe I'm just grasping because I don't understand how this could cause any issues. Can you retry?

[thomcc]

@bors retry

[bors]

⌛ Testing commit 906c360 with merge 32e613b...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing 32e613b to master...

[rust-timer]

Finished benchmarking commit (32e613b): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Max RSS (memory usage)

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

Cycles

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