Seems that when one makes a deep enough nesting of types something which is seemingly type stable just stops being so. Something something union splitting?
struct AA{T}
x::T
end
ff(a::AA) = ff(a.x)
ff(t::Tuple) = mapreduce(ff, max, t; init=0)
ff(a::AbstractArray) = mapreduce(ff, max, a; init=0)
ff(x::Int) = x
# This is fine
let
aa = AA(AA([1,2]))
@code_warntype ff(aa)
end
# This too
let
aa = AA((AA([1,2]),))
@code_warntype ff(aa)
end
# This is not fine
let
aa = AA((AA([AA(1), AA(2)]), AA(3)))
@code_warntype ff(aa)
end
# This looks worse, but is still fine
let
aa = AA((AA([AA(1), AA(2)]), AA([3, 4])))
@code_warntype ff(aa)
end
julia> typeof(aa2)
AA{Tuple{AA{Vector{AA{Int64}}}, AA{Int64}}}
julia> typeof(aa3)
AA{Tuple{AA{Vector{AA{Int64}}}, AA{Vector{Int64}}}}
I think the homogeneity of the 2nd level in the example that looks worse helps the compiler, but not sure how
I did dive in with Cthulhu with remarks turned on. Saw some strange ones deeper in the stack. It may be worth exploring around with that yourself and maybe asking about this in a place where more of the compiler team hangs out.
four methods for ff
? sounds like union splitting to me
I can't even dive into this with Cthulhu on a somewhat recent master
julia> @descend ff(aa)
ERROR: unhandled LimitedAccuracy
Stacktrace:
Even on 1.8 I see some lattice elements that don't look like they should be there (or anywhere, in a valid program). Suffice it to say that this would make a good Cthulhu bug report as well
Don't think it's a cthulhu issue
the stacktrace points to type inference
which makes kind of sense, since @code_warntype
fell back to Any
too
Did this lead to any issues? I recently hit something similar.
similar as in issues with Cthulhu, or do you mean the type stability thing?
cormullion has marked this topic as resolved.
Last updated: Nov 06 2024 at 04:40 UTC