I updated StaticCompiler.jl to provide extensive analysis and generate standalone binaries using Julia 1.12.
Some mods to GPUCompiler.jl were required.
This blog post provides a detailed guide to using the above.
Please let me know what you think!
P.S. I didn’t write a single line of code but carefully shepherded the project to completion.
While experiments of this kind are definitely interesting, I can’t help but wonder: who will bother to review a PR with 22000 lines of code that you didn’t bother to write?
I have no idea, to be honest. The PR has been reviewed by AI, over and over again.
All tests pass, the code works and what’s important to me is that it provides a new capability that wasn’t there before I tackled the project.
Updating StaticCompiler.jl to Julia 1.12 doesn’t hurt either.
Having said that, I released this into the world and it’s my baby now!
I’m responsible for maintaining it and fixing anything that’s broken.
It’s not just about bothering. Very few have the capacity to review that much, regardless whether it’s written by humans or AI.
This is exactly the kind of discussion I wanted to foster!
What do you do in cases like this?
This PR would not make sense piecemeal, it either works as a whole or it doesn’t. I do have a bunch of design and rationale docs for it, maybe I should commit those or add them to the PR discussion.
I can’t talk for anybody else but if I received a 22000 lines PR to one of my packages, I would right out refuse it because
What do you suggest?
Again, if it was one of my packages I’d suggest that they’d either extract manageable pieces for PRs or fork it and make a new package.
Is it just me or did you do the same thing in the OCaml ecosystem this week?
I have. Same issue: DWARF debugging info cannot be added piecemeal. It either works or it doesn’t.
It works like this…
I have no idea if something can be done but I want to try it. So I try it and keep pushing it forward until it either succeeds and I have something working, or it doesn’t.
I managed to succeed in the case of OCaml DWARF debugging info and StaticCompiler.jl. Perhaps, the right question now is whether the latter work can be split into a more manageable set of PRs, now that it’s fully working and tested.
If this was my project I would have expected someone to
Here I just wanted to prove that something substantial, something that moves the goal posts, can be done with little manual coding. I believe I solved this problem. The next problem to tackle is how to properly integrate work like this into existing projects.
I have one more large experiment to run but that’s it. I’m now convinced that AI can write our next compiler!
I’d love to use StaticCompiler with Julia 1.12.
Could you ask the LLMs to identify the minimal set of changes to make StaticCompiler work and skip any enhanced functionality and performance / style improvements? This would allow you to make a minimal PR for the sole purpose of making the package work again. Then ask the LLMs to write up an account about what API changes in Julia 1.12 broke StaticCompiler and why the changes fixed it. A summary could be inserted into your README.
I have no idea if these steps would convince the original maintainers to accept your PR, but it’ll certainly add credibility to your forked repository and I might want to try it out.
I’ll see what I can do.
In the meantime, nothing prevents you from trying my forked repository with Julia 1.12 and running through the examples in the blog post.
All the examples in the blog post have been fully tested and their output should match the blog post.
Indeed, it’s possible.
• Here’s the minimal-change set (functional-only) to get StaticCompiler working on
Julia 1.12, without the extra enhancements, plus the API-breakage notes you asked
for.
Minimal fixes only
Core.Compiler API drift: in src/interpreter.jl, gate the rename to
InternalCodeCache and add versioned shims for get_inference_world, cache_owner,
GPUCompiler/LLVM API drift: in src/StaticCompiler.jl, adjust
GPUCompiler.emit_asm call signature for 1.12 and guard LLVM.merge_functions!
(removed in 1.12). Avoid any unrelated restructuring.
Runtime symbol rename: Julia 1.12 exports ijl_error instead of jl_error; add a
tiny runtime_stubs.c and link it so both symbols exist, or otherwise alias in
the Julia-side stubs. Keep this self-contained; no broader changes to codegen.
Compat bounds: relax Project.toml to include Julia 1.12 and the GPUCompiler/
LLVM versions that work there. Don’t pull in new feature deps; just widen bounds
as needed.
Optional but pragmatic: keep the “exit(0)” in the stub to tolerate the known
What broke in Julia 1.12 (for README summary)
Core.Compiler internal API reshuffle: CodeCache → InternalCodeCache, new helpers
(get_inference_world, cache_owner), and some debug hooks became conditional.
StaticCompiler’s interpreter hooks needed version-gated shims to keep inference
plumbing intact.
GPUCompiler/LLVM surface changes: emit_asm signature shifted (keywords →
positional), and LLVM.merge_functions! was removed in the LLVM bundled with
Julia 1.12. Calls had to be updated/guarded to keep codegen and linking working.
Runtime symbol rename: the exported error symbol moved from jl_error to
ijl_error, so binaries failed to link unless a compatibility symbol was
provided. Adding a small C stub (or equivalent alias) restores the missing
symbol.
Opaque-pointer fallout: GPUCompiler 1.7.4 can emit IR that trips validation
under LLVM 15+ (used by Julia 1.12). The workaround is to surface the warning
but avoid failing the build/tests (e.g., via the stub’s exit behavior) until
GPUCompiler addresses it.
Disclaimer: I am not a maintainer of any of the packages here.
I think if you open a PR for these changes only with a clear description of the changes and their reason, that would be quite welcome. In fact, it would be even easier if you made a PR for each of these points separately. The shorter and self-contained a PR is, the easier the review. In my experience, mixing together many changes does never make review.
After these fixes, a discussion can be held about the enhancements you propose, which look interesting to me.
In your PR, I also notice some things that are not about fixes or features but definitively need discussion with the maintainers and should not be jumbled up with the rest:
I recommend to separate these out as well as these things are very opinionated which further lowers the chances of your PR.
Edit: Also I am curious: How long did that PR take you roughly?
The points here are just to upgrade to Julia 1.12.
The overall set of points is larger but I get the idea.
The PR took me about a work week of monitoring AI and steering it in the right direction. It wasn’t a full work week as AI would go off and work on its own for anywhere from a few minutes to an hour or two. I was switching between different terminal windows with different projects during that time.
I like to call it cooking as opposed to vibe-coding. It’s a slow process and I need to sample the dishes periodically. AI can indeed work for hours at a time as it’s doing with my non-LLVM Zig backend for macOS (there’s one for Intel).
As a (lapsed) maintainer of StaticCompiler, I agree. There’s no way I’m spending the required time to review a monster PR like this which is mostly slop unless it’s broken down, structured more, and better motivated.
What is slop to you?
Does the code look bad?
Are design decisions wrong?
Are you just anti-AI and strictly pro- artisanal coding?