one more question emerged from the discussion with Keno, that all the hard work with modification of IRCode and manual typing is useless, since the only nice way to seamlessly put the modified IRCode to compilation pipeline is through untyped CodeInfo, which is a bit sad to me. Keno has mentioned that an alternative is to define own AbstractInterpreter . Are there some materials I can use for inspiration?
Seems to me that Diffractor is defining two interpretters and JET has its own interpreter. But before extracting the idea from these projects, I wonder if there exist some conceptual document, where I can read about it.
I agree that this remains a big gap in the compiler plugin and IR manipulation story. It’s been 4 years since that AbstractInterpreter pipeline PR landed, and 3/4 years since opaque closures were added/conceived. Yet the only options which seem to work in practice if one needs codegen are genfuncs over unoptimized IR or using GPUCompiler. Some rough parameters on what to expect and when would be great—are we talking 3, 5, 10 years out for a fully fleshed alternative?
None specific to Julia that I’m aware of, other than what you already know of from the manual and @aviatesks blog. This is generally compiler territory, so lots of non-julia literature on abstract interpretation is available, but that topic is VERY deep.
From my own experiments with the abstract interpretation framework, getting a custom interpreter to work is doable but finicky (there’s a reason why JET development is coupled so tightly to julia development), while a custom type lattice for inferring different properties is nigh impossible.
If you find any other literature that’s useful in your journey, please do share!
Thanks for pointing this to me. I do not know, how I could forget it despite reading that block few months ago.
Thanks a lot. Not sure I will find something, but I am putting my notes here, but not sure if I will have time to finish the Petite Diffractor. My vacation ended and I need to return to normal job.
Do you have any material containing your experiments? Either I have a very bad mental model of the infrastructure, or I did not found any nice and simple example of use.
I have looked to MixTape, Umlaut, Diffractor, and original PR but none of them contain what they want.
Umlaut “just” takes the IRCode and process it, which good for what is intended, but really great usecase.
MixTape is something I have not really fully understood. Not all examples are working and the documentation is scarce
Diffractor has an example for 2nd stage of forward diff, but it effectively takes the IRCode, rewrites it and return a function by OpaqueClosure, which is again cool, but not as interesting as Reverse.
Original example in PR 33955 no longer works (no blame, it is expected since this part of Julia is changing, which is good), but it just implements a counter without any codecache.
Part of the problem might be that my mental model about AbstractInterpreter is wrong. I imagine it as some special overlays that has its own cache of compiled code (and other stuff) and in case of cache miss, it compiles the code using its own tweaked compilation pipeline optionally using NativeInterpreter.
If the above would be true, then I can create my PetiteDiffractor that it will return the code for primal computation and pullback, and when pullback will be called, I can intercept the cache miss and create the pullback. So a bit like generated function.
Finaly a question. Does anyone know about a relatively simple example demonstrating the real usecase of AbstractInterpreter machinery?
Not really - I never got far enough with them to have them in any form of shareable or documentable state. As far as I’m aware, there are no simple examples of use, and digging through base/compiler/abstractinterpretation.jl is basically required.
That sounds right to my ears, but I’m also not really well versed in these internals, so that doesn’t really mean anything I do think there are some tricky edge cases when it comes to wrapping a different interpreter, and I think either Keno, Shuhei or Jameson at one point or another told me that it’s kind of impossible to get the wrapping right and preserve the semantics/judgements the NativeInterpreter would make, keeping the resulting code sound. Maybe I misunderstood something there though.
A piece of code actually demonstrating that would indeed be something!
I do think there are some tricky edge cases when it comes to wrapping a different interpreter, and I think either Keno, Shuhei or Jameson at one point or another told me that it’s kind of impossible to get the wrapping right and preserve the semantics/judgements the