-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
ensure proper handling of sparams for widened compile signatures #47667
Conversation
@nanosoldier |
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Interesting that ["misc", "julia", ("macroexpand", "evalpoly")] was slightly hurt and insertionsort sortperm was slightly helped by this. But fortunately no issues seem to have been detected |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
That did surprisingly badly. I will need to dig into those |
Found one of the main causes. Still need to look more into
and
|
This behaved a bit differently than Base.rewrap_unionall, which meant it might make types like `Any where T` from `supertype(struct A{T} <: Any)`. This can confuse subtyping, which does not expect other types to appear to be wider than Any.
In some instances, the preferred compilation signature will require sparams to be provided at runtime. When we build the cache around these, we need to make sure the method instance we are calling has those values computed for the current signature, and not use the widened signature. But we can still compile for the widened signature, we just need to make sure we create a cache entry for every narrower call signature. Fix #47476
Follow-up issue found while working on #47476
…rarg methods And fix a related accuracy issue in jl_isa_compileable_sig Follow-up issue found while working on #47476
Fix #47476