inlining: Use tmeet on inserted PiNode types for extended lattices
#54105
Conversation
This file contains hidden or 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
Member
|
I don't know if this makes sense. The type was not refined in the base lattice. I think the external absint may want to set this itself when doing the lattice extension. |
Member
Author
|
In the case I hit this, we're running with an extended optimizer lattice where the input to the PiNode is already an extended element, so that the new type we insert does not end up being a subtype. |
topolarity
force-pushed
the
ct/refine-pi
branch
from
ebd3e24 to
a4cad91
Compare
topolarity
changed the title
PiNodes for refinementtmeet on inserted PiNode types for extended lattices
Keno
approved these changes
Apr 17, 2024
aviatesk
approved these changes
Apr 18, 2024
Member
aviatesk
left a comment
aviatesk
left a comment
There was a problem hiding this comment.
@nanosoldier runbenchmarks("inference", vs=":master")
Member
|
@nanosoldier |
Collaborator
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Member
|
The benchmark looks fine. |
For extended lattice elements, the type of the resulting PiNode can end up imprecise when `tmeet(argextype(argex), mft) ⊑ mft`
topolarity
added a commit
to topolarity/julia
that referenced
this pull request
Apr 23, 2024
The motivation for this is the same as JuliaLang#54105, where the return types being filled in by inference can in general be imprecise when running the compiler with an extended lattice. This PR is very incomplete - There are at least 6+ more places in `inlining.jl` where we hard-code return types that will need similar treatment.
topolarity
force-pushed
the
ct/refine-pi
branch
from
99a6efc to
140ea49
Compare
topolarity
added a commit
to topolarity/julia
that referenced
this pull request
Apr 23, 2024
The motivation for this is the same as JuliaLang#54105, where the return types being filled in by inference can in general be imprecise when running the compiler with an extended lattice. This PR is very incomplete - There are at least 6+ more places in `inlining.jl` where we hard-code return types that will need similar treatment.
Keno
pushed a commit
that referenced
this pull request
Apr 24, 2024
The motivation for this is the same as #54105, where the return types being filled in by inference can in general be imprecise when running the compiler with an extended lattice. Note that this PR is very incomplete. There are at least 6+ more places in `inlining.jl` where we hard-code return types that will need similar treatment, but for now this resolves some downstream bugs from these imprecise types.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
For extended lattice elements, the type of the resulting PiNode can end up imprecise when
tmeet(argextype(argex), mft) ⊑ mftThat said, it's not entirely clear to me what our
IR_FLAG_REFINEDobligations are in the first place. Are we supposed to mark any statements that are widened past what inference would have seen? If so, it seems like we fall far short of that.