-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Do one round of DestProp at mir-opt-level=2 #105577
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit a586167a54a2505492cbd6f6d66cee28d76670da with merge 8e6760e82a081fb624e777d52ef744c1def2f593... |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (8e6760e82a081fb624e777d52ef744c1def2f593): 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.
|
@JakobDegen Based on the perf run above, are you interested in this? |
This comment has been minimized.
This comment has been minimized.
80cd856
to
984584f
Compare
FYI I have no idea why the codegen tests are failing in CI, they pass locally and I can't reproduce the CI failure. I've tried flipping quite a few options in my config and none seem to produce the test failure. |
638a58d
to
fb1443d
Compare
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
r? rust-lang/compiler |
fb1443d
to
e2bf4b9
Compare
r? @oli-obk |
oh wow, that's an amazing find. typeck and borrowck actually get faster because this causes rustc to improve, offsetting regressions which do work in optimized_mir. @bors r+ rollup=never |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@craterbot abort |
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot build |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@craterbot run mode=build-only |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
…iasko Various cleanups to dest prop This makes fixing the issues identified in rust-lang#105577 easier. A couple changes - Use an enum with names instead of a bool - Only call `remove_candidates_if` from one place instead of two. Doing it from two places is far too fragile, since any divergence in the behavior between those callsites is likely to be unsound. - Remove `is_constant`. Right now we only merge locals, so this doesn't do anything, and the logic would be wrong if it did. r? `@tmiasko`
The crater run found nothing, as expected. We would need a way to ensure that we have |
I flipped crater to build mode, so that should have run the changes from your PR I think? |
I'm pretty sure crater's build mode is a debug build, which is It looks like craterbot supports setting rustflags: https://github.com/rust-lang/crater/blob/master/docs/bot-usage.md#experiment-requirements |
If we do another run, let's wait for the changes I have pending to land first, specifically the fix for stack size and dealing with moves |
☔ The latest upstream changes (presumably #106139) made this pull request unmergeable. Please resolve the merge conflicts. |
Waiting on DestProp improvement |
Since #107449, it seems highly unlikely that any applying any kind of cleverness like this will let DestinationPropagation be a compile time improvement. So I think the status quo is fine and there's nothing to do here: DestinationPropagation can stay opt-in, for things like cranelift. |
Based on some brief experimentation with DestinationPropagation, it seems like sometimes we run a lot of rounds, where the first round does a lot more than any of the later rounds. So it seems like doing just the first round is probably a much better compile time tradeoff than doing all of them.