-
Notifications
You must be signed in to change notification settings - Fork 5
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
UnionAll triggers "ccall
requires the compiler"
#39
Comments
ccall
requires the compiler"ccall
requires the compiler"
Hmm, not sure what's up here. The issue seems to be that we never compile the function (so using CassetteOverlay
@MethodTable MyTable
mypass = @overlaypass MyTable
world = Base.get_world_counter()
const CC = Core.Compiler
@inline function signature_type_by_tt(ft::Type, tt::Type)
u = Base.unwrap_unionall(tt)
return Base.rewrap_unionall(Tuple{ft, u.parameters...}, tt)
end
function methodinstance(ft::Type, tt::Type)
sig = signature_type_by_tt(ft, tt)
match, _ = CC._findsup(sig, nothing, world)
match === nothing && throw(MethodError(ft, tt, world))
mi = CC.specialize_method(match)
return mi::CC.MethodInstance
end
ft = typeof(mypass)
tt = Tuple{Type{UnionAll}, TypeVar, Type{Array{TypeVar(:T,Integer)}}}
mi = methodinstance(ft, tt)::CC.MethodInstance
# inference fails, resulting in the interpreter firing
try
mypass() do
UnionAll(TypeVar(:T,Integer), Array{TypeVar(:T,Integer)})
end
catch err
Base.showerror(stdout, err)
Base.show_backtrace(stdout, catch_backtrace())
end
println()
# inference asserts
@show @ccall jl_type_infer(mi::Any, world::Csize_t, false::Cint)::Any So somehow doing |
If anyone else is running into this issue, I worked around this by introducing an extra "primitive" to the overlaypass: primitives = quote
# ...
@inline function (self::$PassName)(::Type{UnionAll}, v, t)
return UnionAll(v, t)
end
# ...
end This fixed the issue in the OP but I'm not sure if it is the best solution or doesn't introduce other nasty behaviour. |
The problem seems to be that the signature |
When dynamic dispatch occurs for the generated function and the dispatch signature is `!isdispatchtuple` (e.g. since it includes a `Type`-object argument with a free type variable), it will result in unintended code generation, leading to issues like #39 and #45. In this commit, the generated function is now not marked as `:generated_only`, and it will simply fallback to original implementations. This fix introduces a regression where overlays will not occur for the entire call graph of such `!isdispatchtuple` dynamic dispatches. But since it would require a redesign of the runtime system to completely resolve this issue, this regression seems to be acceptable for now.
When dynamic dispatch occurs for the generated function and the dispatch signature is `!isdispatchtuple` (e.g. since it includes a `Type`-object argument with a free type variable), it will result in unintended code generation, leading to issues like #39 and #45. In this commit, the generated function is now not marked as `:generated_only`, and it will simply fallback to original implementations. This fix introduces a regression where overlays will not occur for the entire call graph of such `!isdispatchtuple` dynamic dispatches. But since it would require a redesign of the runtime system to completely resolve this issue, this regression seems to be acceptable for now.
When dynamic dispatch occurs for the generated function and the dispatch signature is `!isdispatchtuple` (e.g. since it includes a `Type`-object argument with a free type variable), it will result in unintended code generation, leading to issues like #39 and #45. In this commit, the generated function is now not marked as `:generated_only`, and it will simply fallback to original implementations. This fix introduces a regression where overlays will not occur for the entire call graph of such `!isdispatchtuple` dynamic dispatches. But since it would require a redesign of the runtime system to completely resolve this issue, this regression seems to be acceptable for now.
EDIT:
I reduced this error further to:
Comparing
@code_lowered
between without and with pass:I logged some variables inside transform_stmt and found the
:foreigncall
expression is being transformed into$(Expr(:foreigncall, :(:jl_type_unionall), Any, svec(Any, Any), 0, :(:ccall), :(%6), :(%3)))
.I don't see what's different here compared to the example from this issue #14. Any help would be appreciated!
Original issue
The following example throws an error.
I can work around this by not using list comprehensions but was wondering if you know what's going on?
I'm using a somewhat recent Julia nightly, my versioninfo:
The text was updated successfully, but these errors were encountered: