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.

Sign up for GitHub

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

Jump to bottom

Make _apply use the append_any function from its calling module #26001

Closed
Keno opened this issue Feb 12, 2018 · 3 comments
Closed

Make _apply use the append_any function from its calling module #26001

Keno opened this issue Feb 12, 2018 · 3 comments

Comments

@Keno
Copy link
Member

Keno commented Feb 12, 2018

In the builtin code for _apply, we have the following:

(jl_function_t*)jl_get_global(jl_top_module, jl_symbol("append_any"));

I think it would be better to use jl_base_relative_to the module of the caller
to avoid a new top module breaking code in an old top module.
@JeffBezanson
Copy link
Sponsor Member

Conceptually I agree, but this would be slower and/or trickier to implement. We haven't done it since having multiple top modules is not formally supported.

@vtjnash
Copy link
Sponsor Member

vtjnash commented May 1, 2019

I think we could readily change the lowering to explicitly include the desired iterate function itself, if we want to do this: f(args...) ==> (call (core '_apply) (top 'iterate) ,f ,@args).

Might need a slightly different name than Core._apply (so we put a deprecation shim in place), but thoughts on whether that's an acceptable approach?

@JeffBezanson
Copy link
Sponsor Member

Yes that seems like a good approach to me. _apply is not exported and lowering is allowed to change, so I think we can change it.

@vtjnash vtjnash mentioned this issue May 7, 2019
Merged
@vtjnash vtjnash mentioned this issue Sep 22, 2019
Merged
Keno added a commit that referenced this issue Oct 5, 2019
@Keno
Add a builtin that allows specifying which iterate method to use
5b07ba2 
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 added a commit that referenced this issue Oct 8, 2019
@Keno
Add a builtin that allows specifying which iterate method to use
511a50d 
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 added a commit that referenced this issue Oct 11, 2019
@Keno
Add a builtin that allows specifying which iterate method to use
677195d 
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 added a commit that referenced this issue Oct 12, 2019
@Keno
Add a builtin that allows specifying which iterate method to use
a3228b7 
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 added a commit that referenced this issue Oct 12, 2019
@Keno
Add a builtin that allows specifying which iterate method to use (#33356
e39c4d8 
)

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 Keno closed this as completed Oct 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@vtjnash @JeffBezanson @Keno