# Zig on MLIR **URL:** \ **Category:** Brainstorming\ **Created:** [June 8, 2024, 5:42pm UTC](https://ziggit.dev/t/zig-on-mlir/4652 "2024-06-08T17:42:47Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![MMUTFX2053](https://ziggit.dev/user_avatar/ziggit.dev/mmutfx2053/32/2451_2.png) [@MMUTFX2053](https://ziggit.dev/u/MMUTFX2053)\ **Post date:** [June 8, 2024, 5:42pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/1 "2024-06-08T17:42:47Z")
i was watching an interview about mojo, and the developer, Chris Lattner said that it runs on MLIR, the successor to LLVM, since Zig uses a LLVM backend, is Zig going to switch eventually, or is there no need for that ? ---
**Author:** ![n0s4](https://ziggit.dev/user_avatar/ziggit.dev/n0s4/32/2227_2.png) [@n0s4](https://ziggit.dev/u/n0s4)\ **Post date:** [June 8, 2024, 6:11pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/2 "2024-06-08T18:11:51Z")
As I understand, Zig will gradually move away from LLVM, not to any other backend but just to do everything itself: > > > This issue is to fully eliminate LLVM, Clang, and LLD \*libraries\* from the Zig p…roject. The remaining ties to these projects are as follows: > \* \[\] #8726 > \* \[x\] #8727 > \* \[\] #17749 > \* \[\] #17751 > \* \[\] #17750 > \* \[\] LLVM > \* \[x\] #13265 > \* \[x\] C backend - 1742/1792 tests passing (97%) (@jacobly0 et al.) > \* \[\] x86 backend - 1721/1792 tests passing (96%) (@jacobly0, @kubkon, et al.) > \* \[\] wasm backend - 1611/1765 tests passing (91%) (@Luukdegram) > \* \[\] aarch64 backend > \* \[\] ~optimization passes~ not actually a prerequisite for this proposal. The clang package mentioned below will be able to provide LLVM optimizations as well. > \* \[\] #17807 > \* \[\] Clang > \* \[\] ~#16268~ not actually a prerequisite for this proposal > \* \[\] ~#16269~ not actually a prerequisite for this proposal > \* \[x\] C++ source files in zig's repository are built by clang when bootstrapping > \* \[x\] #15657 > \* \[\] compiling assembly files > \* \[\] Compiling C++, Objective-C, Objective-C++, etc. files. Solve with a clang package that can be depended on via the zig build system. > \* \[\] \`zig cc\` / \`zig c++\`. Solve with an independent package that serves the exact same use case. > \* \[x\] #17752 > \* \[x\] #17753 > \* \[\] #9828 > > Note that there would still be an LLVM backend for outputting \`.bc\` files (#13265), but the Zig compiler would lack the capability to compile .bc files into object files. LLVM or Clang would need to be installed and invoked separately for that use case. > > In exchange, Zig gains these benefits: > \* All our bugs are belong to us. > \* The compiler becomes trivial to build from source and to bootstrap with only a C compiler on the host system. > \* We stop dealing with annoying problems introduced by Linux distributions and package managers such as Homebrew related to LLVM, Clang, and LLD. There have been and continue to be \[many\](https://github.com/ziglang/zig/issues?q=is%3Aissue+homebrew+). > \* The Zig compiler binary goes from about 150 MiB to 5 MiB. > \* Compilation speed is increased by orders of magnitude. > \* We can implement our own optimization passes that push the state of the art of computing forward. > \* We can attract research projects such as \[alive2\](https://github.com/AliveToolkit/alive2) > \* We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs. > > Please read my other comments in this issue before replying: > \* https://github.com/ziglang/zig/issues/16270#issuecomment-1615388680 > \* https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 ---
**Author:** ![MMUTFX2053](https://ziggit.dev/user_avatar/ziggit.dev/mmutfx2053/32/2451_2.png) [@MMUTFX2053](https://ziggit.dev/u/MMUTFX2053)\ **Post date:** [June 8, 2024, 6:14pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/3 "2024-06-08T18:14:46Z")
that sounds like a crazy amount of work ---
**Author:** ![n0s4](https://ziggit.dev/user_avatar/ziggit.dev/n0s4/32/2227_2.png) [@n0s4](https://ziggit.dev/u/n0s4)\ **Post date:** [June 8, 2024, 6:20pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/4 "2024-06-08T18:20:13Z")
…yup 😅 I fear I don’t know the full story, may be worth looking into the linked thread. ---
**Author:** ![dude\_the\_builder](https://ziggit.dev/user_avatar/ziggit.dev/dude_the_builder/32/557_2.png) [@dude\_the\_builder](https://ziggit.dev/u/dude_the_builder)\ **Post date:** [June 8, 2024, 7:36pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/5 "2024-06-08T19:36:27Z")
From what I’ve read, the idea is to treat LLVM as just another backend option, unlike the current situation where it’s a required dependency. When the transition is complete, a custom and fast x86 backend will be used for Debug builds, and LLVM would be an option for producing optimized release builds, but not the only option; so maybe MLIR could be used as another option too. ---
**Author:** ![nyc](https://ziggit.dev/user_avatar/ziggit.dev/nyc/32/1167_2.png) [@nyc](https://ziggit.dev/u/nyc)\ **Post date:** [June 8, 2024, 7:50pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/6 "2024-06-08T19:50:23Z")
I thought MLIR compiled to LLVM IR? If so, then I think zig already has its own pre-LLVM IR layer. ---
**Author:** ![MMUTFX2053](https://ziggit.dev/user_avatar/ziggit.dev/mmutfx2053/32/2451_2.png) [@MMUTFX2053](https://ziggit.dev/u/MMUTFX2053)\ **Post date:** [June 8, 2024, 8:07pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/7 "2024-06-08T20:07:02Z")
would be awesome if zig could eventually do everything on its own, but im guessing its hard to compete with llvm, since its supported by so many big corps and has an insane amount of optimizations ---
**Author:** ![Validark](https://ziggit.dev/user_avatar/ziggit.dev/validark/32/646_2.png) [@Validark](https://ziggit.dev/u/Validark)\ **Post date:** [June 8, 2024, 8:29pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/8 "2024-06-08T20:29:57Z")
Fair enough, but you could also say that other compilers should have as good cross-compilation support as Zig, or should support incremental linking, but Zig is not at the bottom of the list in terms of compiler tech. Actually it’s at the top of the list in a lot of categories. I think it’s possible we can develop something better in the Zig community. ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [June 8, 2024, 9:04pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/9 "2024-06-08T21:04:47Z")
MLIR offers no advantages unless one is targeting heterogeneous architectures: GPU, TPU, and so on. Zig is a CPU focused language, there’s no advantage to adding it to the project unless that changes. ---
**Author:** ![dmurph](https://ziggit.dev/user_avatar/ziggit.dev/dmurph/32/2963_2.png) [@dmurph](https://ziggit.dev/u/dmurph)\ **Post date:** [July 14, 2024, 6:54pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/10 "2024-07-14T18:54:50Z")
> MLIR offers no advantages unless one is targeting heterogeneous architectures: GPU, TPU, and so on. AFAIK don’t think that’s totally true - its trying to stay ahead of (and allow) architecture improvements that exist (and are under development) everywhere. For example, most CPUs have matrix multiplication instructions, and MLIR makes that much easier to allow the compiler to figure that out, which ends up resulting in much faster code. I may be wrong though 🙂 ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [July 14, 2024, 10:15pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/11 "2024-07-14T22:15:26Z")
That sounds like Mojo hype to me. A lot of that going around lately. Given the standing of LLVM in software, and the relationship MLIR and LLVM have, if MLIR innovates techniques which result in genuinely faster CPU code (and not just VC-backed hype trading on Chris Lattner’s reputation), those techniques will end up in LLVM. MLIR isn’t pixie dust, it’s a sub-project of LLVM. ---
**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\ **Post date:** [July 15, 2024, 12:38am UTC](https://ziggit.dev/t/zig-on-mlir/4652/12 "2024-07-15T00:38:06Z")
> [@mnemnion](#): > > those techniques will end up in LLVM I am not sure if that will be the case for everything. From [https://mlir.llvm.org](https://mlir.llvm.org): > Other lessons have been incorporated and integrated into the design in subtle ways. For example, LLVM has non-obvious design mistakes that prevent a multithreaded compiler from working on multiple functions in an LLVM module at the same time. MLIR solves these problems by having limited SSA scope to reduce the use-def chains and by replacing cross-function references with explicit [`symbol reference`](https://mlir.llvm.org/docs/LangRef/#symbol-reference-attribute). That quote and this video [https://youtu.be/ovYbgbrQ-v8?t=3500](https://youtu.be/ovYbgbrQ-v8?t=3500) sound to me like MLIR may be able to do things that can’t easily be integrated into LLVM and also like it isn’t merely a sub project. ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [July 15, 2024, 2:28am UTC](https://ziggit.dev/t/zig-on-mlir/4652/13 "2024-07-15T02:28:08Z")
It’s easy to promise a lot when you haven’t done squat yet. We’ll see what happens. Until then, my position is that LLVM will take what it needs to from MLIR, and the latter will be mostly useful on chips which aren’t CPUs. On the other hand, if someone wants to spearhead a whole MLIR backend for Zig, don’t let me stop you! ---
**Author:** ![MoAlyousef](https://ziggit.dev/user_avatar/ziggit.dev/moalyousef/32/335_2.png) [@MoAlyousef](https://ziggit.dev/u/MoAlyousef)\ **Post date:** [July 16, 2024, 6:12am UTC](https://ziggit.dev/t/zig-on-mlir/4652/14 "2024-07-16T06:12:01Z")
There is also work to make use of MLIR for clang (see llvm/clangir and llvm/polygeist). That said, flang, the LLVM-based fortran compiler, already uses MLIR. gfortran, the gcc fortran compiler, still outperforms it in most benchmarks IIRC. ---
**Author:** ![carlosecb](https://ziggit.dev/user_avatar/ziggit.dev/carlosecb/32/5545_2.png) [@carlosecb](https://ziggit.dev/u/carlosecb)\ **Post date:** [June 6, 2025, 6:22pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/15 "2025-06-06T18:22:19Z")
Hi! I know this is an old thread but I gotta say, MLIR isn’t just Mojo hype at all! It’s actually a great framework for flexible compiler infrastructure. It allows compiler devs to leverage boiler plate passes and is useful even as a standalone IR framework, allowing you to build a frontend, optimizations and backend completely decoupled from the main dialects if preffered. Regarding what MoAlyousef mentioned, CIR (ClangIR) is aiming to become the main clang solution, currently on it’s way to become upstreamed. On the other end, there’s CIRCT, which is a hardware synthesis framework based on MLIR but doesn’t require using an MLIR frontend. Also, it’s already used by blue chip companies for reliable production level compilers. That all being said, I hope zig moves toward mlir. Even for single CPU targeting, it allows better parallelism inference and boilerplate code reusability. Still, unlike LLVM IR, it doesn’t tie you into using mainstream tools. It allows you to choose whatever parts you want from it and build your own stuff. ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [June 6, 2025, 7:58pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/16 "2025-06-06T19:58:38Z")
> [@carlosecb](#): > > I hope zig moves toward mlir Not even a snowball’s chance in hell. ---
**Author:** ![carlosecb](https://ziggit.dev/user_avatar/ziggit.dev/carlosecb/32/5545_2.png) [@carlosecb](https://ziggit.dev/u/carlosecb)\ **Post date:** [June 6, 2025, 8:40pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/17 "2025-06-06T20:40:07Z")
thanks for matching my enthusiasm, that was very kind ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [June 6, 2025, 9:02pm UTC](https://ziggit.dev/t/zig-on-mlir/4652/18 "2025-06-06T21:02:53Z")
I’m not sure if you’re being sarcastic. If you are, I’m sorry I didn’t mean to offend. I don’t even know where to begin an analysis of why to not use MLIR in Zig. It’s difficult for me to even take the suggestion seriously. I suppose I would start by challenging the problem statement, while pointing out how much of a downside it would be to go from zero dependencies to a dependency on LLVM, C++, and all its other dependencies, including bootstrapping ones such as bash, python, and cmake.