Yes, this is a kind of a follow-up from that thread. I pretty much relate to what @mrufsvold said there.
So thanks for sharing the state of the art!
The compiler plugin project was exactly was I was hoping for… The design docs really summarize the situation (at least of two years ago) and a good plan looking forward.
I’ll take a look at opaque closures and maybe at how Diffractor.jl uses them.
As for AbstractInterpreter, what’s the story? I think Base.code_ircode already gives me the optimized IR, and is internally calling some interpreter.
I guess at some point I will stop looking for tools and just try to hack at whatever I want to do.
I’m interested in performance optimization. For example, I’m intrigued by how better escape analysis (and shape inference) could lead to more stack allocations of otherwise GC-ed variables.
I would also like to contribute to static compilation, and I found StaticCompiler.jl to be too much of a hack, as it uses the GPU Compiler pipeline, and I don’t understand why you can’t just use the native pipeline. I guess it would be better supported in the long run in that case. In that regard, I found Compiler3 static.jl very interesting. It ccalls jl_create_native to generate an .o file of a single function.
In any case, if I manage to do any of this, I’ll try to make sure to document properly.