always try inlining functions which do not call other functions

[lcnr]

a bit broken, I accidentally rebased #75495 while it was still closed

r? @wesleywiser like before, not yet ready for merge

[lcnr]

rebased on top of #77306 meaning that all inlining ICE I know of are fixed

let's try to get a perf run here

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit d91b7490909d1aff17c37fbbe3d51a8823e59431 with merge b07bb178f07169aa2e38cad62befd47aecc28342...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: b07bb178f07169aa2e38cad62befd47aecc28342 (b07bb178f07169aa2e38cad62befd47aecc28342)

[rust-timer]

Queued b07bb178f07169aa2e38cad62befd47aecc28342 with parent d62d3f7, future comparison URL.

[rust-timer]

Finished benchmarking try commit (b07bb178f07169aa2e38cad62befd47aecc28342): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[wesleywiser]

Really interesting results!

Incremental shows lots of regressions (although some wins too) which I think actually makes sense. Inlining makes our functions bigger which means changes to them take longer and also makes it more prone that a change to one function will cause other calling functions to also need to be re-compiled.

Putting aside the incremental tests, there's a lot of green down the results! Check builds are regressed nearly universally so we should probably disable inlining when in check only mode. Debug and opt builds look really good though! There's some nice wins on real world crates: 7% on clap-rs-opt, 5.1% on webrender-debug, 5% on hyper-2-opt, 4.5% on ripgrep-debug and 4.1% on ripgrep-opt. The rustc bootstrap results are also impressive: nearly 9% wallclock time improvement on rustc-middle!

[Mark-Simulacrum]

I would ignore rustc bootstrap timing for now, I'm still experimenting with variance reduction strategies. 9% might not be representative.

[lcnr]

pushed some changes which might reduce the negative perf impact here

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 9c25e949a8bf81185042f39e57604e44df7ab6a9 with merge 61b181866f0ce12555c356bf46da832c9a45a22e...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 61b181866f0ce12555c356bf46da832c9a45a22e (61b181866f0ce12555c356bf46da832c9a45a22e)

[rust-timer]

Queued 61b181866f0ce12555c356bf46da832c9a45a22e with parent 6ac6c67, future comparison URL.

[rust-timer]

Finished benchmarking try commit (61b181866f0ce12555c356bf46da832c9a45a22e): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[lcnr]

difference between the two perf runs https://perf.rust-lang.org/compare.html?start=b07bb178f07169aa2e38cad62befd47aecc28342&end=61b181866f0ce12555c356bf46da832c9a45a22e&stat=instructions%3Au

[lcnr]

let's try again 😅

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit bd954f9012e18717651abd20aa754cf4fd57bdfa with merge 5c1c73fd351cfb72d9ec163bc1f61db9e9bf2b63...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 5c1c73fd351cfb72d9ec163bc1f61db9e9bf2b63 (5c1c73fd351cfb72d9ec163bc1f61db9e9bf2b63)

[rust-timer]

Queued 5c1c73fd351cfb72d9ec163bc1f61db9e9bf2b63 with parent 12f667f, future comparison URL.

[rust-timer]

Finished benchmarking try commit (5c1c73fd351cfb72d9ec163bc1f61db9e9bf2b63): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[lcnr]

@bors try @rust-timer queue exclude=deeply-nested

updated metadata encoding to only use 1 byte

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 6b17a76 with merge 2f0d06e5b8f278ed4180d80b7b6be06be6da3b36...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 2f0d06e5b8f278ed4180d80b7b6be06be6da3b36 (2f0d06e5b8f278ed4180d80b7b6be06be6da3b36)

[rust-timer]

Queued 2f0d06e5b8f278ed4180d80b7b6be06be6da3b36 with parent 9832374, future comparison URL.

[rust-timer]

Finished benchmarking try commit (2f0d06e5b8f278ed4180d80b7b6be06be6da3b36): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[bors]

@rust-timer: 🔑 Insufficient privileges: not in try users

[bjorn3]

^ cc @pietroalbini

[pietroalbini]

@Mark-Simulacrum could you take a look at this? I don't think I changed anything on the bors side regarding permissions.

[Mark-Simulacrum]

@bors rollup=never

[lcnr]

It looks like we end up with more calls to optimized_mir in some full benchmarks which is surprising to me.
Not yet sure why this is the case. Will try to spend some more time on this next week.

[lqd]

@oli-obk and @tmiasko figured out why in this zulip thread for unicode_normalization-check: the optimized MIR is always encoded for closures (and some of those call the big tables functions in this benchmark).

This was a bit surprising, and there wasn't an obvious reason this was done (apart from the case of generators), and may have just been an oversight. This might also be interesting to #80347.

Here's my interpretation of what oli and tomasz suggested trying (errors would be my own), and it did bring back the counts of the eval_to_allocation_raw, eval_to_const_value_raw and normalize_generic_arg_after_erasing_regions queries to their previous numbers (in the dozens rather than thousands) on the unicode_normalization-check benchmark.

[lcnr]

closing in favor of #81079