Turn TrapUnreachable off by default

[jonas-schievink]

Now that #28728 is fixed, there's no longer a risk of programs executing past the end of a function, so we don't have to put a trap instruction there anymore.

This should ever so slightly shrink the average Rust program.

(the second commit is a drive-by-fix that reverts an incorrect part of 62e7331, which made the alloc-optimisation.rs test fail with my system's LLVM)

[rust-highfive]

r? @oli-obk

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

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 4d545d9 with merge c95266130c4724381de0a769a741cf934583d48d...

[bors]

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

[rust-timer]

Queued c95266130c4724381de0a769a741cf934583d48d with parent 7bf0736, future comparison URL.

[rust-timer]

Finished benchmarking commit (c95266130c4724381de0a769a741cf934583d48d): comparison url.

Summary: This change led to large relevant improvements 🎉 in compiler performance.

• Large improvement in instruction counts (up to -2.3% on full builds of piston-image)

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

[nikic]

FWIW upstream is considering turning on TrapUnreachable or some variant thereof on by default, to at least prevent zero-size functions.

I think a more conservative step we can take is to enable the NoTrapAfterNoreturn option, which probably is the form in which the vast majority of unreachable appears in rust code (basically after every panic), and also the one where it has little practical benefit.

[oli-obk]

I don't know enough about the effects of this to review this properly.

r? @nikic

[pnkfelix]

FWIW upstream is considering turning on TrapUnreachable or some variant thereof on by default, to at least prevent zero-size functions.

I think a more conservative step we can take is to enable the NoTrapAfterNoreturn option, which probably is the form in which the vast majority of unreachable appears in rust code (basically after every panic), and also the one where it has little practical benefit.

I think this should be revised to take the more conservative approach quoted here.

Changing to S-waiting-on-author for that revision

[JohnCSimon]

Ping from triage:
@jonas-schievink Can you please post the status of this PR?