Repository navigation
-Znext-solver filter out some uninteresting opaques while canonicalization - #164368
ShoyuVanilla wants to merge 1 commit into
Conversation
|
|
|
|
||
| fn build_multiple<'a>() -> impl Sized { | ||
| spawn(async { build_dependencies().await }); | ||
| //[next]~^ ERROR overflow evaluating the requirement |
There was a problem hiding this comment.
This isn't overflowing anymore and I guess this is an unexpected improvement
There was a problem hiding this comment.
Actually, this was in the triage list as a regression 😅
https://hackmd.io/RQF9zqx8R3aBl_-gr2YU6w?view#Pass--gt-Regular-Fail
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
`-Znext-solver` filter out some uninteresting opaques while canonicalization
c7c7a1a to
7ff1473
Compare
7ff1473 to
eea7880
Compare
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (307e94e): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=iffy rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.2%, secondary 3.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.5%, secondary 1.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 492.307s -> 489.052s (-0.66%) |
|
Does this help with other compile-time regressions in the ui test triage table? |
|
Let me check (completely forgot about it while pondering upon hr opaques 😅 ) |
|
Yeah, all four tests in compiletime and one test in hang for it compiles instataneously |
| /// Filter out not-so-useful opaque types, i.e. whose hidden type is not | ||
| /// mentioned in `variables` so far and has any var within opaque type key | ||
| /// that is not mentioned in the same manner. This helps the perf by avoiding | ||
| /// having many inputs/outputs differing only on some not interesting opaques | ||
| /// and even saves us from overflowing due to having too many opaques. |
There was a problem hiding this comment.
What's the reasoning of defining not-so-useful like this? 🤔
I thought we could drop opaques whose hidden types are infers and not in var_values. And we'd also keep opaques whose hidden infers are mentioned in other opaque keys for the reason you said above the fixpoint computation. The latter part feels slightly hacky though.
| } else { | ||
| predefined_opaques_in_body | ||
| }; | ||
| rest_canonicalizer.filter_and_canonicalize_opaque_types(predefined_opaques_in_body); |
There was a problem hiding this comment.
filtering in response should be enough to prevent overflows?
uncertain about whether this filters out "useful` opaques. I need to think more on this.
There was a problem hiding this comment.
Yeah, that would be enough for preventing overflows and from the input side it would help only the perf due to better cache hits.
On what is useful and what is useless opaque (for both this and your above comment), yeah, I have sth in my mind but haven't tried to clearly state them anywhere. I'll try that 😅
| } | ||
| } | ||
|
|
||
| // This should be synced with `Canonicalizer`'s `TypeFolder` implementation. |
There was a problem hiding this comment.
We also have a mentioned_region visitor in filter_irrelevant_region_constraints.
It feels disorganized to have them in multiple places.
We could add next solver revisions for them then :> |
Context: #t-types/trait-system-refactor > higher ranked opaque type perf
Partially extracted from #161414
Fixes #151806
rust-lang/trait-system-refactor-initiative#242 is not fixed by this. The overflow goes away by this, but as I wrote in the above zulip stream, hr opaque types aren't replaced by infer vars and that prevents the pending obligation containing it from being fully normalized and solved in the root context.
r? adwinwhite as we've talked on this in the zulip stream (cc @lcnr I guess you might be busy in EuroRust 😅)