Avoid codegen for Result::into_ok in lang_start

[Mark-Simulacrum]

This extra codegen seems to be the cause for the regressions in max-rss on #86034. While LLVM will certainly optimize the dead code away, avoiding it's generation in the first place seems good, particularly when it is so simple.

#86034 produced this diff for a simple fn main() {}. With this PR, that diff becomes limited to just a few extra IR instructions -- no extra functions.

Note that these are pre-optimization; LLVM surely will eliminate this during optimization. However, that optimization can end up generating more work and bump memory usage, and this eliminates that.

[rust-highfive]

r? @yaahc

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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 76e71b012bd77dc310ce036e14fb56b2d9e0a43d with merge 526cb50d2abbf6ee2ee3c62cabe2ce1735313f63...

[bors]

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

[rust-timer]

Queued 526cb50d2abbf6ee2ee3c62cabe2ce1735313f63 with parent 2c7bc5e, future comparison URL.

[nagisa]

I feel like we may want to open-code map_err in the function above as well which would likely help too.

[rust-timer]

Finished benchmarking commit (526cb50d2abbf6ee2ee3c62cabe2ce1735313f63): comparison url.

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

• Large improvement in instruction counts (up to -4.4% on incr-full builds of helloworld)

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

[Mark-Simulacrum]

I feel like we may want to open-code map_err in the function above as well which would likely help too.

lang_start_internal is already codegen'd as part of std, so unless we're doing LTO or similar, it's body doesn't really matter. If LTO is running, then based on some local testing it looks like we pull in tons of code from std anyway (and backtrace etc) so it really doesn't matter whether we're using map_err or not.

I also want to avoid doing too much in this particular PR - makes it harder to compare things in perf, for example - so I am going to go ahead and @bors r=nagisa

[bors]

📌 Commit db5ecd5 has been approved by nagisa

[bors]

⌛ Testing commit db5ecd5 with merge 6cdd42f...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing 6cdd42f to master...

[rust-timer]

Finished benchmarking commit (6cdd42f): comparison url.

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

• Large improvement in instruction counts (up to -4.4% on incr-full builds of helloworld)

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

@rustbot label: -perf-regression