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

Add a builtin that allows specifying which iterate method to use #33356

Merged
merged 1 commit into from
Oct 12, 2019

Conversation

Keno
Copy link
Member

@Keno Keno commented Sep 21, 2019

When using the Casette mechanism to intercept calls to _apply,
a common strategy is to rewrite the function argument to properly
consider the context and then falling back to regular _apply.
However, as showin in JuliaLabs/Cassette.jl#146,
this strategy is insufficient as the _apply itself may recurse into
various iterate calls which are not properly tracked. This is an
attempt to resolve this problem with a minimal performance penalty.
Attempting to duplicate the _apply logic in julia, would lead to
code that is very hard for inference (and nested Cassette passes to
understand). In contrast, this simply adds a version of _apply that
takes iterate as an explicit argument. Cassette and similar tools
can override this argument and provide a function that properly
allows the context to recurse through the iteration, while still
allowing inference to take advantage of the special handling of _apply
for simple cases.

@vtjnash
Copy link
Member

vtjnash commented Sep 22, 2019

If you delete the code for _apply, you get to close your issue #26001 too :)

@Keno Keno requested a review from JeffBezanson October 4, 2019 02:00
@Keno
Copy link
Member Author

Keno commented Oct 4, 2019

I don't think we can get rid of regular _apply in a minor release. Even though it's not exported, people do regularly call it manually.

@vtjnash
Copy link
Member

vtjnash commented Oct 4, 2019

Sure. I think we should change the lowering at least (plus then the new code gets tested "for free").

@@ -635,6 +635,8 @@ end
function abstract_call(@nospecialize(f), fargs::Union{Nothing,Vector{Any}}, argtypes::Vector{Any}, vtypes::VarTable, sv::InferenceState, max_methods = sv.params.MAX_METHODS)
if f === _apply
return abstract_apply(argtypes[2], argtypes[3:end], vtypes, sv, max_methods)
elseif f === _apply_iterate
return abstract_apply(argtypes[3], argtypes[4:end], vtypes, sv, max_methods)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
return abstract_apply(argtypes[3], argtypes[4:end], vtypes, sv, max_methods)
return abstract_apply(argtypes[2], argtypes[3], argtypes[4:end], vtypes, sv, max_methods)

Copy link
Member Author

Choose a reason for hiding this comment

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

You're saying we should pass through the iterate method through abstract_apply and plumb it down into the code that does the iteration emulation? Agreed. Will do.

@Keno
Copy link
Member Author

Keno commented Oct 5, 2019

Updated with adjustments to inference, inlining and lowering to use the new intrinsic.

@Keno
Copy link
Member Author

Keno commented Oct 11, 2019

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

@nanosoldier
Copy link
Collaborator

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

When using the Casette mechanism to intercept calls to _apply,
a common strategy is to rewrite the function argument to properly
consider the context and then falling back to regular _apply.
However, as showin in JuliaLabs/Cassette.jl#146,
this strategy is insufficient as the _apply itself may recurse into
various `iterate` calls which are not properly tracked. This is an
attempt to resolve this problem with a minimal performance penalty.
Attempting to duplicate the _apply logic in julia, would lead to
code that is very hard for inference (and nested Cassette passes to
understand). In contrast, this simply adds a version of _apply that
takes `iterate` as an explicit argument. Cassette and similar tools
can override this argument and provide a function that properly
allows the context to recurse through the iteration, while still
allowing inference to take advantage of the special handling of _apply
for simple cases.

Also change the lowering of splatting to use this new intrinsic directly,
thus fixing #26001.
@Keno
Copy link
Member Author

Keno commented Oct 12, 2019

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

@nanosoldier
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants