-
Notifications
You must be signed in to change notification settings - Fork 35
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
Open discussion - support for dynamic pass creation #175
Comments
This is very hard to do performantly. The pass operates as part of a generated function which only receives the types of the arguments. In theory you can hoist runtime values into the typesystem, but that will create a dynamic dispatch site and poison type information.
Now you can write a pass:
The real question will be when you change the metadata and how you decide to do so. |
Okay, so that's a big red The alternative is something like this: function Cassette.overdub(ctx::DefaultCtx, fn::typeof(some_foo), args...)
t_args = map(args) do a
typeof(a)
end
ir = lower_to_ir(fn, t_args...)
ir = some_transform(ir, ctx.metadata)
ret = Base.invokelatest(IRTools.func(Main, ir), nothing, args...)
return ret
end which appears to work, and would allow me to implement the functionality I want. It also looks like I could get the caching working. However, are there performance gotchas with This solution is not It seems like incremental computation is a good use case for why you might want this capability, but I'm unsure if there's an idiomatic way of expressing this without reflection and munging. |
That is better written as:
|
For a probabilistic programming library I’ve been developing, I’ve identified a set of optimizations which require something akin to the ability to dynamic create and register passes inside overdub.
In essence, depending on context metadata, I would like the pass to do different things e.g. depending on the runtime dependency graph for randomness (which could change as I run the program) I would like to configure a pass to remove parts of the program which are irrelevant (i.e. incremental computation). This pass would be configured by runtime data.
The alternative to doing this in Cassette is to do this with IRTools: run a pass, dynamically compile a new method body to an anonymous function, then recurse into an invokelatest call. I’m a little concerned about this alternative, because it appears sub-optimal from a performance perspective.
The other rock in the shoe is the caching of pass results - i.e. if I see the same runtime data, I would like to re-use the results from a previously computed pass.
Is something like this possible with the current compiler infrastructure? Is there an optimal way to do this?
The text was updated successfully, but these errors were encountered: