-
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
Normalize opaques w/ bound vars #100980
Normalize opaques w/ bound vars #100980
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 9e54f90d09293845fda4a881eabd40d78d5d0a95 with merge a4aab122ee1970839d7697c919e2c222d4260af2... |
☀️ Try build successful - checks-actions |
Queued a4aab122ee1970839d7697c919e2c222d4260af2 with parent addacb5, future comparison URL. |
Finished benchmarking commit (a4aab122ee1970839d7697c919e2c222d4260af2): 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.
Footnotes |
9e54f90
to
156c5ca
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 156c5cae434d88a89c8b6b84544dd9964b850842 with merge 47f3dd411b2c7ef6a2728fc318238097436b567e... |
☀️ Try build successful - checks-actions |
Queued 47f3dd411b2c7ef6a2728fc318238097436b567e with parent 76f3b89, future comparison URL. |
Finished benchmarking commit (47f3dd411b2c7ef6a2728fc318238097436b567e): 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.
Footnotes |
156c5ca
to
c7c5a1b
Compare
@bors try @rust-timer queue r? types cc @rust-lang/types I could use some help gauging the correctness of the last commit. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit c7c5a1bdd19dfee669a5e460a1e7ec3f085c0d64 with merge 4bf67d41f0d4a2f98e2ed48f7a0b7a61bada64b9... |
forgot about this and thought it was already merged 😁 @bors r+ rollup=never happy to finally see this landing |
☀️ Test successful - checks-actions |
Finished benchmarking commit (8ab71ab): 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.
Footnotes |
I wonder if |
@aliemjay I don't think so? We handle binders differently there, so I suspect the same pathological case where we create way too many region variables just doesn't happen. |
…-r-hard, r=oli-obk Revert "Normalize opaques with escaping bound vars" This caused a perf regression in rust-lang#103423, cc `@skyzh` this should fix rust-lang#103423. reverts rust-lang#100980 r? `@oli-obk`
…-r-hard, r=oli-obk Revert "Normalize opaques with escaping bound vars" This caused a perf regression in rust-lang#103423, cc `@skyzh` this should fix rust-lang#103423. reverts rust-lang#100980 r? `@oli-obk`
…th-late-bound-vars-again, r=jackh726 Normalize opaques with late-bound vars again We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below). I attempted to fix this in rust-lang#100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was rust-lang#103423, which caused the project to hang on build. Another one was rust-lang#104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (rust-lang#104133). However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from rust-lang#103423 (comment), and it doesn't seem to hang any more... Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of rust-lang#103423) that we were encountering when normalizing opaques with bound vars the last time around: * rust-lang#104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim) * rust-lang#104833 (removing an `identity_future` fn that was wrapping desugared future generators) ... so given that I can see: * No significant regression on rust perf bot (rust-lang#107620 (comment)) * No timeouts in crater run I did (rust-lang#107620 (comment), rechecked failing crates in rust-lang#107620 (comment)) ... and given that this PR: * Fixes rust-lang#104601 * Fixes rust-lang#107557 * Fixes rust-lang#109464 * Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f68) I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work. r? types
First, we reenable normalization of opaque types with escaping late bound regions to fix rust-lang/miri#2433. This essentially reverts #89285.
Second, we mitigate the perf regression found in #88862 by simplifying the way that we relate (sub and eq) GeneratorWitness types.
This relies on the fact that we construct these GeneratorWitness types somewhat particularly (with all free regions found in the witness types replaced with late bound regions) -- but those bound regions really should be treated as existential regions, not universal ones. Those two facts leads me to believe that we do not need to use the full
higher_ranked_sub
machinery to relate two generator witnesses. I'm pretty confident that this is correct, but I'm glad to discuss this further.