-
-
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
Support execution of code from external abstract interpreters #52964
base: master
Are you sure you want to change the base?
Conversation
One thing I particularly enjoyed about Cassette was that composition is well defined. This proposal ignores composition, compiler instances don't form a stack and there is no expectation that the output of one is meant to be consumed by another. For Cassette uninferred IR was a viable communication layer, but with compiler instances customization can occur along many levels and we run into the pipeline ordering problem. The hope would be that using compiler instance we could build an actual "compiler plugins" infrastructure that allows for the registration of passes/intrinsics and provides sensible composition, but that seems further away and I do think we need some experimentation with compiler customization first before we tackle that. |
408391e
to
ef35f71
Compare
ef35f71
to
4f975b0
Compare
1726c2d
to
2ce7b5e
Compare
887526f
to
e825798
Compare
1. Introduced a task-local inherited (nee ScopedValue) compiler field 2. Allow compilation and execution of code generated by foreign abstract interpreters A new primitive `call_within` is introduced that switches the compiler instance. The compiler instance is used for cache-lookups, compilation request, and dispatch.
0aaf405
to
4f16213
Compare
|
||
# FIXME: Currently doesn't infer and ends in "Skipped call_within since compiler plugin not constant" | ||
overlay(f, args...) = CustomMethodTables.overlay(CustomMT, f, args...) | ||
@test_broken overlay(sin, 1.0) == cos(1.0) # Bug in inference, not using the method_table for initial lookup |
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.
This is due to jl_lookup_generic
not taking into account the custom method table.
Currently external abstract interpreters are succesfully used to power analysis,
compilation for external targets like GPU, but there currently doesn't exist a
mechanism within Julia to execute the output of these abstract interpreters and
the community has developed various work-arounds.
uses ccall to call from Julia native to Enzyme controlled land. It furthermore
needs to detect dynamic callsites and replaces them to functions controlled by Enzyme.
f(args...)
to calls to
overdub(ctx, f, args...)
. While this has worked in Cassette.jl for along time, it also leads to hard to read backtraces and overly relies on generated functions.
This PR is a combination of two ideas:
Concretly this PR introduces
abstract type CompilerInstance end
that allows for the creation of temporaryAbstractInterpreter
instances,it then uses a new built-in
call_within
to switch between compiler instances, furthermore the compiler instance is also the owner ofthe corresponding
CodeInstances
.After that it is mostly and exercise of threading the compiler instance through in the right places.
TODO
jl_nothing
as a owner token and use the correct one.call_within
call_within
Example: Cassette style tracer
This PR doesn't do anything about how to work with the IR and write compiler plugins,
it also doesn't provide any hooks for compiler instances to modify the LLVM pipeline,
but a below is a prototype of a Cassette type tracer. Where we have a
prehook
and a
posthook
function to execute over the callgraph.