Hacker News Reader

Comment by Athas | Hacker News Reader

I'm the developer of a language that I think is in the target audience of MLIR: https://futhark-lang.org

I'm still not completely certain MLIR addresses the difficulties I face, which is exactly to design the specific IR that can express the passes I need. Having outside constraints seems like it would just make this work harder, and I'm not sold that the reusable components offered by MLIR offset this. At some point I probably will try generating MLIR from the compiler midend, though, just to see whether it might be a good idea.

The thing that concerns me the most might be that using MLIR seems to require writing your compiler in C++. LLVM can be accessed by non-C++ languages just fine, because it's just a consumer of bytecode, but the whole point of MLIR is for the IR to be extensible, and that will presumably require custom C++ to introduce the desired bespoke structures. In comparison, it's rare that a compiler needs custom LLVM passes.

View on HN

Cool, I've seen the PLDI talk a couple of years ago! Would you mind describing your potential use case on https://llvm.discourse.group/c/llvm-project/mlir, there may be more people who are able to help or have similar needs.

Regarding C++, I would argue that MLIR is roughly as accessible from other languages as LLVM. That is, if you want just to run passes or construct pieces of IR using already-defined constructs, adding the bindings is trivial. However, if you want to add new concepts into the IR, you should do it in the language that the IR is defined in. Most of MLIR operations are actually generated from Tablegen definitions, there's not that much hand-written C++ for that. We can also provide bindings to inspect the IR from different languages, at which point you can envision calling back from C++ to the another language to implement passes. The risk is to end up with the "JSON of compiler IRs" as we call it, where an operation has a string id, a string kind, a list of strings of operation ids producing its operands and so on to a full stringly typed system.

> However, if you want to add new concepts into the IR, you should do it in the language that the IR is defined in.

And isn't that what most users will want to do? The point of MLIR is to provide a framework for writing mid-level IRs, citing among others the Rust compiler as an example. This will invariably involve adding both new concepts and new passes (for example, the Rust IR will presumably wish to represent and check ownership information explicitly), but the Rust compiler is written in Rust, not C++.

Don't get me wrong, I can't really think of a better language for implementing MLIR than C++. Everything that I would find subjectively better would be too obscure to gain industrial traction, and using straight C would probably be too painful. I just suspect that it will limit its use as a universal mid-level IR.

> I can't really think of a better language for implementing MLIR than C++.

C++ being the language of llvm, it makes sense. But surely any language would be good, and memory safe ones with stronger type systems as well would potentially lead to higher quality output, no?

I hadn't heard of Furthark before, very cool project. I've actually had "Learn How to write a compiler by writing an APL that supports GPU-optimized numerical ops." Part of the reason that I was interested in working on such a project (besides the fact that I find APL, GPU compute, and compilers really interesting) Is that I feel like the rise of new compute platforms (GPUs, BLAST accelerators, Neural Net accelerators, Crypto ASICs, etc.) and open hardware (RISC-V) could motivate a new wave of research in compilers (I guess that is what MLIR is).

It's really easy to picture how having a family of programming language for every class of accelerators can go very wrong, but it's kinda cool to picture what it would be like if biology, chemistry, meteorology, astrophysics, and other quantitative fields had open-source hardware accelerators and software stacks that became foundational components which "normal" programmers rarely ever touched. Then when we finally get practical quantum computing down to the size of something that could go in a PCI-E slot, there will already be a compilation toolchain waiting to target it.

I think you are right about needing to use C++ in implementing MLIR dialogs. It does look like you can define a lot of it in TableGen (a sort of python-like declarative language used in LLVM) which generates a lot of the C++ for you. I regret too that MLIR is tied closely to C++ at this point, but I'm still very excited about the possibilities of languages like futhark that make heterogeneous data processing easier to write and more efficient to run.

By the way, do you think futhark could support automatic differentiation?

> By the way, do you think futhark could support automatic differentiation?

I don't see why not. It's similar to other languages that have been the subject of AD research: https://www.microsoft.com/en-us/research/uploads/prod/2019/0...

Concretely, we've only experimented with the usual forward-mode stuff with dual numbers implemented as a library. It works well, but is of course limited in utility.

Reply on news.ycombinator.com