Add a builtin that allows specifying which iterate method to use #33356
Conversation
|
If you delete the code for _apply, you get to close your issue #26001 too :) |
|
I don't think we can get rid of regular |
|
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) | |||
There was a problem hiding this comment.
| 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) |
There was a problem hiding this comment.
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
force-pushed
the
kf/_apply_iterate
branch
from
5bb6d0a
to
5b07ba2
Compare
|
Updated with adjustments to inference, inlining and lowering to use the new intrinsic. |
Keno
force-pushed
the
kf/_apply_iterate
branch
from
5b07ba2
to
511a50d
Compare
Keno
force-pushed
the
kf/_apply_iterate
branch
from
511a50d
to
677195d
Compare
|
@nanosoldier |
|
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
force-pushed
the
kf/_apply_iterate
branch
from
677195d
to
a3228b7
Compare
|
@nanosoldier |
|
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
iteratecalls which are not properly tracked. This is anattempt 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
iterateas an explicit argument. Cassette and similar toolscan 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.