lattice: Don't forget to pass down lattice in Conditional tmerge #47992
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aviatesk
approved these changes
Dec 25, 2022
Keno
force-pushed
the
kf/latticeconddown
branch
from
3340afe
to
c8df7cb
Compare
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Also add some extra cases that before were taken care of by the tmerge_fast_path at the entry to the tmerge code. I briefly considered splitting an extra slow path function to avoid the one `===` in the ConstsLattice, but in the non-equality case that check should be quite fast, so it didn't seem worth it.
Keno
force-pushed
the
kf/latticeconddown
branch
from
c8df7cb
to
6092d77
Compare
|
Added an appropriate fast path, which should hopefully fix the perf regression: @nanosoldier |
|
Your benchmark job has completed - no performance regressions were detected. A full report can be found here. |
vtjnash
added a commit
that referenced
this pull request
Aug 16, 2023
In 162ee48, the added code causes us to violate the tmerge_fast_path requirements on the lattice. This was causing the fall-though from the earlier tmerge_fast_path to not return correct answers to inference anymore. Adding back another tmerge_fast_path, on the types, allows us to recover correctness without regressing accuracy to before #47992. Also added a test case for an example in which tmerge_fast_path does not return a correctly limited answer, since it does not model UnionAll complexity growth.
vtjnash
added a commit
that referenced
this pull request
Aug 21, 2023
In 162ee48, the added code causes us to violate the tmerge_fast_path requirements on the lattice. This was causing the fall-though from the earlier tmerge_fast_path to not return correct answers to inference anymore. Adding back another tmerge_fast_path, on the types, allows us to recover correctness without regressing accuracy to before #47992. Also added a test case for an example in which tmerge_fast_path does not return a correctly limited answer, since it does not model UnionAll complexity growth.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Also add some extra cases that before were taken care of by the tmerge_fast_path at the entry to the tmerge code. I briefly considered splitting an extra slow path function to avoid the one
===in the ConstsLattice, but in the non-equality case that check should be quite fast, so it didn't seem worth it.