Skip to content
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

Merged
merged 6 commits into from
Jan 9, 2017
Merged

Conversation

yuyichao
Copy link
Contributor

@yuyichao yuyichao commented Sep 11, 2016

Replaces #10964 (take 2). Expr(:invoke) makes this significantly easier to implement =)

Summary of changes,

  1. Deprecate the tuple form of invoke and use the tuple type form instead.

    It's much easier to infer/optimize.

  2. Inline invoke call.

Based on #18438 since I hit it when working on this PR. (merged)

Close #9608

@yuyichao
Copy link
Contributor Author

Travis OSX failed with a network issue Restarted.

@@ -1297,7 +1297,7 @@ function ⊑(a::ANY, b::ANY)
end
end

widenconst(c::Const) = typeof(c.val)
widenconst(c::Const) = type_typeof(c.val)
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But widens too much?

Copy link
Member

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

Copy link
Contributor Author

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())

local all = true
local stmts = []
local aei = ex.args[i]
for ty in (ti::Union).types; local ty
Copy link
Contributor

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?

Copy link
Contributor Author

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.

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,
Copy link
Member

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,
Copy link
Member

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;
Copy link
Member

@vtjnash vtjnash Sep 16, 2016

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.

Copy link
Contributor Author

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?

@kshyatt
Copy link
Contributor

kshyatt commented Sep 21, 2016

Rebase?

@yuyichao yuyichao force-pushed the yyc/invoke/inline branch 2 times, most recently from 689235a to 45345bd Compare October 9, 2016 23:29
@yuyichao yuyichao changed the title WIP: Inline invoke (take 3) plus a few other tweaks Inline invoke (take 3) plus a few other tweaks Oct 9, 2016
@yuyichao
Copy link
Contributor Author

yuyichao commented Oct 9, 2016

The TODO is finished and this is ready for review.

@tkelman
Copy link
Contributor

tkelman commented Oct 11, 2016

@nanosoldier runbenchmarks(ALL, vs=":master")

@yuyichao
Copy link
Contributor Author

get_invoke_func

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 Expr(:invoke) to call it? Which sounds like a good api but will make it harder to share code with the normal function call.

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 get_invoke_func won't help too much right now but can still be useful since it might be able to share code path with #13984

@JeffBezanson
Copy link
Member

@yuyichao @vtjnash Should we try to get this into 0.6? I might want to use invoke to fix #7357.

@yuyichao
Copy link
Contributor Author

yuyichao commented Jan 8, 2017

Is #18444 (comment) (last paragraph) ok for now?

@JeffBezanson
Copy link
Member

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?

@yuyichao
Copy link
Contributor Author

yuyichao commented Jan 8, 2017

Yes, the last one should only affect some cases when certain arguments to the invoke is not inferred.

@yuyichao
Copy link
Contributor Author

yuyichao commented Jan 9, 2017

Rebased.

@yuyichao
Copy link
Contributor Author

yuyichao commented Jan 9, 2017

Just in case

@nanosoldier runbenchmarks(ALL, vs=":master")

@yuyichao yuyichao mentioned this pull request Jan 9, 2017
@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

@yuyichao yuyichao merged commit f65673d into master Jan 9, 2017
@yuyichao yuyichao deleted the yyc/invoke/inline branch January 9, 2017 08:59
@tkelman tkelman added the needs news A NEWS entry is required for this change label Jan 9, 2017
@tkelman
Copy link
Contributor

tkelman commented Jan 9, 2017

The deprecation of the tuple form is worth mentioning in NEWS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:inference Type inference performance Must go faster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants