-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Test performance of running MIR inliner on inline(always) function calls #82280
[WIP] Test performance of running MIR inliner on inline(always) function calls #82280
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit c2230893d572fed6a1809edc67098f5bf08be1c9 with merge 386d02a615f9f2266eeae4d38d62aba0d4b994de... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Queued 386d02a615f9f2266eeae4d38d62aba0d4b994de with parent 0148b97, future comparison URL. |
Finished benchmarking try commit (386d02a615f9f2266eeae4d38d62aba0d4b994de): 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 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 |
A few small wins, lots of significant losses. The main culprit seems to be increased incremental cache load times. This is probably proof that addressing #80536 will be critical before we see compile time wins from this optimization. |
c223089
to
71afdfc
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 71afdfc4d02f8d9b030954134b2242bde5106c7c with merge bd198f8ac3c38a1e932bacccc5a2cdfb569c1972... |
☀️ Try build successful - checks-actions |
Queued bd198f8ac3c38a1e932bacccc5a2cdfb569c1972 with parent 4f20caa, future comparison URL. |
Finished benchmarking try commit (bd198f8ac3c38a1e932bacccc5a2cdfb569c1972): 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 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 |
Ok, from the results it looks like we need to turn inlining off during incremental compilation, too. |
This comment has been minimized.
This comment has been minimized.
Const eval no longer runs MIR optimizations so unless this is getting run as part of a MIR optimization like const-prop, there can be unused type parameters even if polymorphization is enabled.
7bf524b
to
d28bda0
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
…_message, r=michaelwoerister Correct caller/callsite confusion in inliner message `callee_body` is the MIR `Body` for the `callsite.callee` so this message basically says `"Inline {bar span} into bar"` when it should say `"Inline bar into foo"`. Extracted out of rust-lang#82280
AFAIK we were using old LLVM pass manager back when this wad tested. Do you think it'd be worth to retest with the new pass manager? |
I think it definitely would be worth retesting with NewPM but a naïve rebase ICEs the compiler during bootstrap and I haven't had time to investigate further. |
☔ The latest upstream changes (presumably #91475) made this pull request unmergeable. Please resolve the merge conflicts. |
…ll, r=oli-obk Enable MIR inlining Continuation of rust-lang#82280 by `@wesleywiser.` rust-lang#82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in rust-lang#81567 are now fixed, except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching, in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.
r? @ghost