-
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
Run various queries from other queries instead of explicitly in phases #108118
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wesleywiser (or someone else) soon. Please see the contribution instructions for more information. |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
⌛ Trying commit a1bf293aea5384252c0d7227f46dcf534667aeb1 with merge 41c8d3a20cad3d4de552339500551ada93f0d722... |
@@ -529,8 +529,6 @@ pub fn check_crate(tcx: TyCtxt<'_>) -> Result<(), ErrorGuaranteed> { | |||
tcx.hir().for_each_module(|module| tcx.ensure().check_mod_item_types(module)) | |||
}); | |||
|
|||
tcx.sess.time("item_bodies_checking", || tcx.typeck_item_bodies(())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is going to ensure that typecheck errors for all functions are reported without this call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also regresses the quality of the output of -Ztime-passes
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as mentioned in the main post
This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can cause e.g. const eval which invokes borrowck, which invokes typeck, ...
we already didn't produce correct time tracking for it
I think this is a good change, but maybe a safer intermediate step would be to "assert" that all the queries were run in the "passes" for now. This would ensure that we don't accidentally make a query more lazy, then skip something (accidentally). |
Hmm... we don't have the setup for doing that (also doing it at that phase won't work, as it may get run later). I'll see if I can add something to the query system for asserting that a query has been run |
☔ The latest upstream changes (presumably #101841) made this pull request unmergeable. Please resolve the merge conflicts. |
I looked into it, and we're already relying on the |
@rust-timer build 41c8d3a20cad3d4de552339500551ada93f0d722 |
This comment has been minimized.
This comment has been minimized.
I'm not sure I agree with the general direction. I'd rather suggest doing the opposite:
The fact that we run |
The problem with those useless dependencies is that e.g. const eval can run on code that doesn't satisfy various checks, leading to surprising bugs and workarounds in const eval. I agree that mir_built may be too early, but at the very least the mir_drops_elaborated_and_const_checked query should not finish before the various checks on the same def id are done. I guess my assumption was that at some point all we have to do is to either call the optimized_mir query for the main function and can compile from just the information from that, or call the analysis query to do a check build. If changing any of this negatively affects incremental, then we should not do it, but I don't see that being an issue in general with this scheme, just with the details of where to add edges. |
Finished benchmarking commit (41c8d3a20cad3d4de552339500551ada93f0d722): 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.
|
Everything but |
about that, do we really add more dependencies with |
Yes,
In those cases, we should rely on the One other symptom is the calls to
From the perf results, I have no proof that it does negatively affect incremental, so no serious grounds on which to block this PR. That's also why I frame it as a design question, more than an operational question. That said, we should merge that PR, as it does not lock anything in a way or the other. I'll have to make my case with an actual PR demonstrating the direction I have in mind 😄. |
This comment has been minimized.
This comment has been minimized.
r=me when @cjgillot is happy 🙂 |
☔ The latest upstream changes (presumably #96840) made this pull request unmergeable. Please resolve the merge conflicts. |
…voking it eagerly. Later queries that are run on all body owners will invoke typeck as they need information from its result to perform their own logic
…aving an explicit phase for them
@bors r+ |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (3462f79): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression 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.
|
Run various queries from other queries instead of explicitly in phases These are just legacy leftovers from when rustc didn't have a query system. While there are more cleanups of this sort that can be done here, I want to land them in smaller steps. This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can invoke e.g. const eval which invokes borrowck, which invokes typeck, ...
typeck in parallel rust-lang#108118 caused `typeck` to be transferred to the serial part (`check_unused`), which made the performance of parallel rustc significantly reduced. This pr re-parallelize this part, which increases the average performance improvement of parallel rustc in `full` and `incr-full` scenarios from [14.4%](rust-lang#110284 (comment)) to [23.2%](rust-lang#110284 (comment)). r? `@cjgillot` cc `@oli-obk` `@Zoxc`
These are just legacy leftovers from when rustc didn't have a query system. While there are more cleanups of this sort that can be done here, I want to land them in smaller steps.
This phased order of query invocations was already a lie, as any query that looks at types (e.g. the wf checks run before) can invoke e.g. const eval which invokes borrowck, which invokes typeck, ...