-
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
use precalculated dominators in explain_borrow #65172
use precalculated dominators in explain_borrow #65172
Conversation
This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example, in rust-lang#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct, but no tests seem to fail as a result of this change in local testing.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@bors r+ The only case where this change can be wrong is in case we have wrong code elsewhere that does not invalidate the cache in some way after doing some modification. Since borrowck does not mutate anything, this change seems perfectly fine to me. |
📌 Commit 4cc707c has been approved by |
@bors r- delegate+ @tanriol would be great if you also added a regression test case. A good test could be just something that runs for a dozen minutes without this fix and completes in under a second with the fix. If that is not feasible, then something that checks whether the compiler terminates with the minimized reproducer from #65131 would also do. |
✌️ @tanriol can now approve this pull request |
✌️ @tanriol can now approve this pull request |
I have also added |
On this case: #65131 (comment) 19.8s (nightly 1.40) vs 0.3s (this branch) <3 |
@nagisa What's the proper way of testing this? As written currently this is a performance-only change, and The options I'm seeing are:
UPD: sorry, this reply was written based on the email notification without noticing the edits. |
How about adding failure tests on https://perf.rust-lang.org/ ? |
The easiest approach is probably a |
The slowdown is not to runtime, but to compilation process, so the alternative would be to... spawn |
Useful trick: When you use |
Ah yeah, sorry, I didn’t wake up entirely before writing that down. In that case this one is an example of a test that invokes |
Hello from triage - this has sat idle for the last 5 days. |
Seemed to be waiting for additional tests. Looks good to me btw :). |
Going to add a test in a couple days. |
I'm confused why we would add this test in-tree instead of as a benchmark to rustc-perf. (Example PR, btw) |
@tmandry Thank you for the example. Is rustc-perf a correct place for, basically, a regression test for error reporting performance in a very specific case of a huge generated function with borrow-check errors? It feels to me a little heavyweight for such a small problem (cluttering of the "all benchmarks" view with an additional graph, for example). Basically, my feeling was that rustc-perf / perf.rust-lang.org is a human-oriented resource, not an automated testing oriented one, and the exact performance of this use case is not something worth permanent human attention. However, if you consider this position wrong, please tell me so and I'll add the test there. |
rustc perf tests will not block landing and will only test retroactively, which is not terrible, but not ideal for issues like these either. That being said glandium suggests there are some sort of a "failure test" mode in rustc-perf? In that case it sounds like a fairly good compromise. |
@bors r+ I am approving this PR for landing due to the large improvement on perf that this gives, with an expectation that a regression test is added as a follow-up PR (either to rustc itself or to rustc-perf or somewhere else entirely?) To track this follow-up work, I am a) removing the |
📌 Commit 4cc707c has been approved by |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 4cc707c has been approved by |
… r=nagisa use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example, in #65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct, but no tests seem to fail as a result of this change in local testing.
☀️ Test successful - checks-azure |
Discussed at T-compiler meeting. Accepted for beta backport. |
[beta] backport rollup This includes a bunch of PRs: * Fix redundant semicolon lint interaction with proc macro attributes #64387 * Upgrade async/await to "used" keywords. #64875 * syntax: fix dropping of attribute on first param of non-method assocated fn #64894 * async/await: improve not-send errors #64895 * Silence unreachable code lint from await desugaring #64930 * Always mark rust and rust-call abi's as unwind #65020 * Account for macro invocation in `let mut $pat` diagnostic. #65123 * Ensure that associated `async fn`s have unique fresh param names #65142 * Add troubleshooting section to PGO chapter in rustc book. #65402 * Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302 * Optimize `try_expand_impl_trait_type` #65293 * use precalculated dominators in explain_borrow #65172 * Fix ICE #64964 #64989
[beta] backport rollup This includes a bunch of PRs: * Fix redundant semicolon lint interaction with proc macro attributes #64387 * Upgrade async/await to "used" keywords. #64875 * syntax: fix dropping of attribute on first param of non-method assocated fn #64894 * async/await: improve not-send errors #64895 * Silence unreachable code lint from await desugaring #64930 * Always mark rust and rust-call abi's as unwind #65020 * Account for macro invocation in `let mut $pat` diagnostic. #65123 * Ensure that associated `async fn`s have unique fresh param names #65142 * Add troubleshooting section to PGO chapter in rustc book. #65402 * Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302 * Optimize `try_expand_impl_trait_type` #65293 * use precalculated dominators in explain_borrow #65172 * Fix ICE #64964 #64989 * [beta] Revert "Auto merge of #62948 - matklad:failable-file-loading, r=petro… #65273 * save-analysis: Don't ICE when resolving qualified type paths in struct members #65353 * save-analysis: Nest tables when processing impl block definitions #65511 * Avoid ICE when checking `Destination` of `break` inside a closure #65518 * Avoid ICE when adjusting bad self ty #65755 * workaround msys2 bug #65762
This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the
MirBorrowckCtxt
. For example, in #65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors.I don't know enough about this part of rustc codebase to know for sure that this change is correct, but no tests seem to fail as a result of this change in local testing.