-
-
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
Inline invoke (take 3) plus a few other tweaks #18444
Conversation
Travis OSX failed with a network issue Restarted. |
eb7ef56
to
28922e0
Compare
28922e0
to
cdafa58
Compare
@@ -1297,7 +1297,7 @@ function ⊑(a::ANY, b::ANY) | |||
end | |||
end | |||
|
|||
widenconst(c::Const) = typeof(c.val) | |||
widenconst(c::Const) = type_typeof(c.val) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typeof should always be correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But widens too much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Widens what? Const.val isn't a Type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
K. I think I was probably confused by the printing and thought it could be.
julia> Core.Inference.print(Core.Inference.Const(sin))
Core.Inference.Const(val=Base.#sin())
cdafa58
to
a41a8f6
Compare
local all = true | ||
local stmts = [] | ||
local aei = ex.args[i] | ||
for ty in (ti::Union).types; local ty |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
local ty
on a separate line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Just note that this is simply moved from where it was.
a41a8f6
to
3e21bc8
Compare
jl_method_t *method = entry->func.method; | ||
jl_typemap_entry_t *tm = NULL; | ||
if (method->invokes.unknown != NULL) { | ||
tm = jl_typemap_assoc_by_type(method->invokes, tt, NULL, 0, 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inexact
possibly needs to be true
(1)
if (func->invokes.unknown == NULL) | ||
func->invokes.unknown = jl_nothing; | ||
|
||
jl_method_instance_t *mfunc = cache_method(mt, &func->invokes, entry->func.value, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may not want to insert into the invokes
cache, unless tt
was a leaf signature
jl_tupletype_t *tt) | ||
{ | ||
if (!jl_is_leaf_type((jl_value_t*)tt)) | ||
return jl_nothing; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overly strict, but seems this should work. I guess you're mimicking jl_get_specialization1? You also need to check that none of the elements are types of types like that other method too then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overly strict
Yeah. There are currently very feel users and most of them should have leaf type (forwarding) so I didn't bother handling more complex cases.
I guess you're mimicking
jl_get_specialization1
Right.
You also need to check that none of the elements are types of types like that other method too then.
Added. I assume the comments below (inexact and caching) does not apply anymore then?
Rebase? |
3e21bc8
to
05068b1
Compare
689235a
to
45345bd
Compare
The TODO is finished and this is ready for review. |
@nanosoldier |
Do you mean to make it return an actual function? In which case we'll need to create a new type in it and it doesn't sound easy or efficient. Or do you mean to use sth like I'm also not sure how much easier this would be. The main complexity in this actually comes from type check and argument order. The type check is a mostly independent patch and commit. The argument order won't be an issue at all when we have linear IR. What about leaving the type check part out (the last commit) and think about changing invoke implementation later? I feel like having a |
Is #18444 (comment) (last paragraph) ok for now? |
Yes, I like the idea of using all but the last commit here for now. That commit has a lot of extra complexity, and IIUC we get all our usual optimizations without it? |
Yes, the last one should only affect some cases when certain arguments to the |
45345bd
to
e03b717
Compare
e03b717
to
b1c47ec
Compare
Rebased. |
Just in case @nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels |
The deprecation of the tuple form is worth mentioning in NEWS |
Replaces #10964 (take 2).
Expr(:invoke)
makes this significantly easier to implement =)Summary of changes,
Deprecate the tuple form of
invoke
and use the tuple type form instead.It's much easier to infer/optimize.
Inline
invoke
call.Based on #18438 since I hit it when working on this PR.(merged)Close #9608