ANN: Mixtape.jl -- a static overlay and optimization tool

Hi all – I’d like to present a small experimental compiler package I’ve been working on with the help of AbstractInterpreter and GPUCompiler (as well as the sick, twisted minds of @vchuravy and @Roger-luo).

If you’d like to use this package, I recommend that you don’t add it from the registry for now – and instead just follow the top pkg lines of the repository.

Here’s the value proposition:

Mixtape.jl is a static method overlay and optimization tool which operates during Julia type inference. It allows you to (precisely) insert semantic-intruding changes to lowered code (e.g. replace CodeInfo , pre-optimize CodeInfo , and create other forms of static analysis tools on uninferred CodeInfo ) before optimization . It also allows you to customize the optimization pipeline – allowing users to write semantic-preserving passes on Core.Compiler.IRCode which operate after inference .

Note : Mixtape.jl manages its own code cache and execution engine through LLVM.jl and GPUCompiler.jl – so it is less part of Julia’s native pipeline, and closer to a separate compiler pipeline. In the future, parts of Mixtape.jl may be integrated into the compiler.

In many respects, it is similar to Cassette.jlbut it is completely static .

Note : the architecture for this package can be found in many other places. The interested reader might look at KernelCompiler.jl, Enzyme.jl, the Julia frontend to brutus, and the compiler interface in GPUCompiler.jl to understand this a bit better.

When in doubt, don’t be afraid of typeinfer.jl and Julia’s SSA form IR!

Here’s a list of pros and cons:

A few upsides!

  1. Completely static – does not rely on recursive pollution of the call stack (see: the overdub issue).
  2. Transforms operate pre-type inference – all semantic-intruding changes happen before type inference runs on the lowered method body.
  3. Mixtape.jl manages its own code cache – and doesn’t interact with the native runtime system (see above).

A few downsides…

  1. Mixtape.jl uses a custom execution engine through GPUCompiler.jl – code which causes GPUCompiler.jl to fail will also cause Mixtape.jl to fail. In practice, this means you can’t use the pipeline on dispatch tuples with Union{As...} or Any – you must specify a non-dynamic type.