Always enable MultipleReturnTerminators #106362
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 68abf63 with merge 312e3e2441955984d5701aa75594e7c07fdb1672... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Didn't know this MIR pass existed. I'm already effectively emulating it in cg_clif: https://github.com/bjorn3/rustc_codegen_cranelift/blob/97e2213c3c31909de388943ac3b1cb024decd6c2/src/base.rs#L310-L325 By the way I think your push caused rust-timer to not get informed about the finished try build. @rust-timer build 312e3e2441955984d5701aa75594e7c07fdb1672 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (312e3e2441955984d5701aa75594e7c07fdb1672): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
rustbot
added
perf-regression
|
That's basically what I expected. This PR breaks a lot of codegen tests, LLVM seems to really benefit from only having one return terminator. But one benchmark gets a fair bit faster, though it is an artificial benchmark. So I think we might be able to get some wins by running optimizations on the multiple return form, then converting back to the single return form before codegen. Ideally this would be a canonicalization done by LLVM or at whatever phase cranelift is doing its conversion. |
|
cg_clif converts from single return terminator -> multiple return terminators while codegening jump terminators. AFAIK Cranelift doesn't canonicalize it back to a single return terminator. I never thoroughly benchmarked this change, but I know it improved runtime performance in some cases. |
|
Yeah. I'm saying that if multiple return terminators is better for MIR optimizations but one is better for LLVM, it would be best to handle that canonicalization somewhere LLVM-specific. |
|
Closing this in favor of work in #106550 (which is very WIP but has more P than this) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When this pass was created, LLVM experts said that LLVM prefers a single return. But for example, this pass produces a lot of simplification of
Option::unwrap_or(and thus possibly other matches?). Let's see what comes out of a perf run...r? @ghost