-
Notifications
You must be signed in to change notification settings - Fork 13k
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] rustc_mir_transform: Add extra ConstProp pass to fold constants at end of MIR-opt #95007
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nagisa (or someone else) soon. Please see the contribution instructions for more information. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
We can check what the perf impact is: @bors try @rust-timer queue |
☀️ Try build successful - checks-actions |
Queued 9522791934643ad3d1bdc0b2b54cab50e81cf971 with parent 461e807, future comparison URL. |
Finished benchmarking commit (9522791934643ad3d1bdc0b2b54cab50e81cf971): comparison url. Summary: This benchmark run shows 30 relevant regressions 😿 to instruction counts.
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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
The change in performance suggests to me that adding another run of this pass is not the right way forward (at any optimization level). I don't see a general way to resolve this sort of a problem with the current infrastructure we have in place right now. It is well known (section 2.2) that not interleaving distinct optimizations until a fix-point will result in sub-optimal results in some cases, and it seems like that's exactly what's happening here. Unfortunately, I do not believe that addressing this sort of problem in general is a tractable problem, and I fear that any attempts to approximate something like this by introducing additional pass runs will likely only provide minimal improvement at a significant compile-time cost. |
Closing given the lack of activity and the comment above. I think the best way forward would be to raise a discussion on Zulip or such to figure out a way forward here. |
Hello! I'm looking at this as a first issue. This seems to be the most straightforward solution, however having two ConstProp passes doesn't sound great for performance, and the first one can't be moved since it enables later MIR passes. Is there a preferred way to solve this? (I could put the second pass under a higher opt level?).