-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Don't cache results of coinductive cycle #96458
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
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit e9e4ab8a5f2bbb6cddd036c62f8339c5232e4b5c with merge c19d1ba0dab84507be11fff585888fa39b00e4b0... |
☀️ Try build successful - checks-actions |
Queued c19d1ba0dab84507be11fff585888fa39b00e4b0 with parent 082e4ca, future comparison URL. |
Finished benchmarking commit (c19d1ba0dab84507be11fff585888fa39b00e4b0): comparison url. Summary:
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 may lead to changes in compiler perf. @bors rollup=never Footnotes |
Fixes rust-lang#96319 The logic around handling co-inductive cycles in the evaluation cache is confusing and error prone. Fortunately, a perf run showed that it doesn't actually appear to improve performance, so we can simplify this code (and eliminate a source of ICEs) by just skipping caching the evaluation results for co-inductive cycle participants. This commit makes no changes to any of the other logic around co-inductive cycle handling. Thus, while this commit could potentially expose latent bugs that were being hidden by caching, it should not introduce any new bugs.
e9e4ab8
to
40c6d83
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 40c6d83 with merge 85755f8c91122429d4224fb842a5752cedfff3e9... |
☀️ Try build successful - checks-actions |
Queued 85755f8c91122429d4224fb842a5752cedfff3e9 with parent a7d6768, future comparison URL. |
Finished benchmarking commit (85755f8c91122429d4224fb842a5752cedfff3e9): comparison url. Summary:
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 may lead to changes in compiler perf. @bors rollup=never Footnotes |
cc @rust-lang/wg-traits @cjgillot - this PR is now ready for review. I tested this on the benchmark from #91598, and verified that it didn't result in an exponential blowup. However, it would probably be a good idea to test this PR on some various 'complex' uses of auto traits, to reduce the chance that this leads to a huge regression missed by our perf suite. |
r=me on the "don't cache" side of things. Not sure if @cjgillot has thoughts. |
On the incr. comp. side, I agree that this is the best solution for now. Devising a clean scheme to handle cycles is very hard, and probably way more brittle. @bors r=jackh726,cjgillot |
📌 Commit 40c6d83 has been approved by |
We could add a test from #96319. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (4799baa): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
No description provided.