Passes over IR about cassette.jl

[jrevels]

Cassette (as it is now) is built for injecting compiler passes into post-lowering, pre-inference IR. Whatever that IR is, is what Cassette has to target - changing that IR (removing slots, permitting phi nodes, etc.) is an upstream issue more than it is a Cassette issue. I certainly agree that it would be nice for Base to provide better infrastructure for working with this stuff.

Using Cassette as a front end to post-type-inference pass injection is potentially feasible, though I wonder whether it would be better to just build a new injection interface directly into the optimizer. Let's discuss that in #67 instead of having two issues open for it. My initial thought is that it's not unlikely that a sane approach to this would require the optimizer to provide a bonafide pass manager anyway.

there is some way to go to really get past "contextual dispatch and metadata propagation" and become a general tool for creating new compilers on top of Julia.

The tone here indicates some misunderstanding regarding the purpose of these features, and the kind of work they were built to facilitate.

Many techniques for nonstandard execution often require similar kinds of compiler passes parameterized on the execution/interpretation domain. Such passes, while ubiquitously applicable, are very difficult to handroll when targeting a language like Julia (and, e.g. much easier to implement on limited DSLs). The whole point of Cassette's contextual dispatch/tagging framework is to automate the harder part of writing these passes, making it easier to derive an implementation given some operational semantics. I don't want to "get past" these core features; I want to implement them.

[MikeInnes]

I realise Cassette is built to implement those features, and that many useful things can be built on top of that higher-level interface too.

My only point is that there's scope for increasing generality here; Cassette can be a tool for implementing some compiler passes that are very similar to contextual dispatch, or it can be an increasingly general tool that could be used for things like SPMD. These issues only reflect what would be necessary for me to use Cassette for my work (which I would like to do, as it seems there's enough overlap).

Of course, one has to decide on scope at some point. If the decision is that Cassette should primarily support contextual dispatch as an interface, and more advanced transformations need to use other tools, that's completely fine too.

[jrevels]

Just to clarify, in case closing the issue came off as dismissive (apologies if it did): I didn't close this issue because I disagree with the spirit of the OP, as I understood it. It would be awesome for Cassette users to be able to exploit new compiler infrastructure and the cool features of the optimizer's new IR.

However, with its current implementation, Cassette has to target the compiler's pre-inference IR, whatever it might happen to be. Expanding to new stages of compilation is an interesting idea, hence moving that particular discussion to #67.

I closed this issue because the non-#67 part is basically an upstream issue. Improving pre-inference IR (or merging it with the optimizer's IR) is an important topic that merits discussion, but it's a Base issue, not a Cassette issue.

Cassette can be a tool for implementing some compiler passes that are very similar to contextual dispatch, or it can be an increasingly general tool that could be used for things like SPMD.

If the decision is that Cassette should primarily support contextual dispatch as an interface, and more advanced transformations need to use other tools, that's completely fine too.

Generality improvements (e.g. "what kind of passes can one inject with Cassette") are unfortunately not bottlenecked on Cassette, but rather Julia's compiler itself. Cassette's API already allows one to perform arbitrary compilation passes using arbitrary Julia functions, subject only to the limitations imposed by the compiler itself. The contextual dispatch/tagging interfaces are only parts of that API, and are there to make it easier to write certain kinds of traditionally difficult passes. These interfaces are not in competition with Cassette's ability to inject general passes.

I definitely agree that Cassette's API could be significantly improved with more features/utilities. I fully appreciate your insights and am happy to figure out what we can work on to facilitate your work.

[MikeInnes]

Zygote now contains the tools needed to do this, i.e. constructing IR and converting phis back to slots that inference can handle.