Hacker News Reader

Comment by AndyKelley | Hacker News Reader

How does migrating to MLIR address the problem?

The higher abstraction level it provides over the LLVM IR, making language frontends and compiler passes less dependent on its semantics.

Huh?? That can only make frontends' jobs more tricky.

Yet is being embraced by everyone since its introduction in 2019, with its own organization and conference talks.

So maybe all those universities, companies and the LLVM project know kind of what they are doing.

- https://mlir.llvm.org/

- https://llvm.github.io/clangir/

- https://mlir.llvm.org/talks/

No need to make a weird appeal to authority. Can you just explain the answer to my question in your own words?

I am only familiar with MLIR for accelerator-specific compilation, but my understanding is that by describing operations at a higher level, you don’t need the frontend to know what LLVM IR will lead to the best final performance. For instance you could say "perform tiled matrix multiplication" instead of "multiply and add while looping in this arbitrary indexing pattern", and an MLIR pass can reason about what pattern to use and take whatever hints you’ve given it. This is especially helpful when some implementations should be different depending on previous/next ops and what your target hardware is. I think there’s no reason Zig can’t do something like this internally, but MLIR is an existing way to build primitives at several different levels of abstraction. From what I’ve heard it’s far from ergonomic for compiler devs, though…

You see it as appeal to authority, I see it as the community of frontend developers, based on Swift and Rust integration experience, and work done by Chris Lattner, while working at Google, feedbacking into what the evolution of LLVM IR is supposed to look like.

Mojo and Flang, were designed from scratch using MLIR, as there are many other newer languages on the LLVM ecosystem.

I see it as the field experience of folks that know a little bit more than I ever will about compiler design.

As the guy currently handling Zig's LLVM upgrades, I do not see this as an advantage at all. The more IR layers I have to go through to diagnose miscompilations, the more of a miserable experience it becomes. I don't know that I would have the motivation to continue doing the upgrades if I also had to deal with MLIR.

LLVM project sees that otherwise, and the adoption across the LLVM community is quite telling where they stand.

That doesn't seem like a good argument for why Zig ought to target MLIR instead of LLVM IR. I think I'd like to see some real-world examples of compilers for general-purpose programming languages using MLIR (ClangIR is still far from complete) before I entertain this particular argument.

Would Flang do it? Fortran was once general purpose.

https://github.com/llvm/llvm-project/blob/main/flang/docs/Hi...

Maybe the work in Swift (SIL), Rust (MIR), Julia (SSAIR) that were partially the inspiration for MLIR, alongside work done at Google designing Tensorflow compiler?

The main goal being an IR that would accomodate all use cases of those high level IRs.

Here are the presentation talk slides at European LLVM Developers Meeting back in 2019,

https://llvm.org/devmtg/2019-04/slides/Keynote-ShpeismanLatt...

Also you can find many general purpose enough users around this listing,

https://mlir.llvm.org/users/

Are you saying that Fortran was once a general purpose programming language, but somehow changed to no longer be one?

Yes, because we are no longer in the 1960's - 1980's.

C and C++ took over many of the use cases people where using Fortran for during those decades.

In 2025, while it is a general purpose language, its use is constrained to scientific computing and HPC.

Most wannabe CUDA replacements keep forgetting Fortran is one of the reasons scientific community ignored OpenCL.

So you're saying that the changes made to Fortran have made it more specialized?

Reply on news.ycombinator.com