bad inference edges being created sometime #49350
Labels
Comments
vtjnash
added
compiler:inference
|
There is a similar MethodInstance observed for |
|
More similar bugs from inference: |
|
Could it be SnoopPrecompile doing something weird? |
|
No, looks like at least some of this is a concrete-eval bug. For example, here's a what Cthulhu said about one of the calls: Then we ended up with an edge to |
|
Some of the Base.IteratorSize issues come from this sort of thing: |
|
I think #49404 will fix many of these. The rest likely come from recursion-limiting. I think backedge handling already could handle that case (where MethodInstance might be wider than the Method), but we don't yet have the equivalent code for staticdata_utils.c |
|
Looking closer again now, we are losing this other edge too, because of the intersection with |
vtjnash
added a commit
that referenced
this issue
Apr 19, 2023
Even if we have a new method that is more specific than the method it is
replacing, there still might exist an existing method that is more
specific than both which already covers their intersection.
An example of this pattern is adding
Base.IteratorSize(::Type{<:NewType})
causing invalidations on
Base.IteratorSize(::Type)
for specializations such as
Base.IteratorSize(::Type{<:AbstractString})
even though the intersection of these is fully covered already by
Base.IteratorSize(::Type{Union{}})
so our new method would never be selected there.
This won't detect ambiguities that already cover this intersection, but
that is why we are looking to move away from that pattern towards
explicit methods for detection in closer to O(n) instead of O(n^2): #49349.
Similarly, for this method, we were unnecessarily dropping it from the
MethodTable cache. This is not a significant latency problem (the cache
is cheap to rebuild), but it is also easy to avoid in the first place.
Refs #49350
vtjnash
added a commit
that referenced
this issue
Apr 20, 2023
Even if we have a new method that is more specific than the method it is
replacing, there still might exist an existing method that is more
specific than both which already covers their intersection.
An example of this pattern is adding
Base.IteratorSize(::Type{<:NewType})
causing invalidations on
Base.IteratorSize(::Type)
for specializations such as
Base.IteratorSize(::Type{<:AbstractString})
even though the intersection of these is fully covered already by
Base.IteratorSize(::Type{Union{}})
so our new method would never be selected there.
This won't detect ambiguities that already cover this intersection, but
that is why we are looking to move away from that pattern towards
explicit methods for detection in closer to O(n) instead of O(n^2): #49349.
Similarly, for this method, we were unnecessarily dropping it from the
MethodTable cache. This is not a significant latency problem (the cache
is cheap to rebuild), but it is also easy to avoid in the first place.
Refs #49350
|
Concrete-eval returning incorrect and bad edges will be fixed by #54894, since it will then be impossible for concrete-eval to record edges. That code is not supposed to have edges anyways, as that violates the knowledge we had of the completeness of the prior inference to conclude that the return is consistent. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There seems to be MethodInstance edges created at some point with bad type information (while building OmniPackage), such as this one:
There should only be one method for this re-lookup, but obviously that fails quite badly when we try to go verify that fact in the cache. This is unnecessarily expensive. Why does it make that bad edge?
The text was updated successfully, but these errors were encountered: