[HN Gopher] Building a Compiler with Multi-Level Intermediate Re...
___________________________________________________________________
Building a Compiler with Multi-Level Intermediate Representation
(MLIR) (2020) [pdf]
Author : informalo
Score : 102 points
Date : 2023-05-02 17:32 UTC (5 hours ago)
(HTM) web link (llvm.org)
(TXT) w3m dump (llvm.org)
| Q6T46nT668w6i3m wrote:
| I love MLIR. The modularity and friendly abstractions make it
| incredibly flexible. I've now used it to write _multiple_ domain-
| specific optimizations and transformations for some of my recent
| research! It truly bridges the gap between different devices
| (CPUs, GPUs, TPUs, etc.). I pray more people adopt it so it
| doesn't end up abandoned!
| yukIttEft wrote:
| Sounds very interesting. Could you explain a bit more what you
| did and why it was easier with MLIR?
| comfypotato wrote:
| It's so hard to get a complete environment up and running. I
| had a 700-level project that was ripe for MLIR, and I just
| couldn't figure out all the tools. I ended up managing with
| just clang.
|
| Much of MLIR requires compiling from source, from what I can
| tell, and I just could've figure out exactly what to build so
| that I had access to all of the tool chain from clang to MLIR.
| mathisfun123 wrote:
| this is quickly getting better
|
| >Much of MLIR requires compiling from source, from what I can
| tell
|
| you can get apt packages from https://apt.llvm.org/ and build
| projects out of tree. you can also get packages from conda
| (https://github.com/conda-forge/mlir-feedstock). finally, if
| you look around on github you'll find tarred up releases too
| maintained by downstream users
| (e.g.https://github.com/ptillet/triton-llvm-releases).
|
| you can also (as of very recently) build mlir-opt plugins
| just like for clang:
|
| https://github.com/llvm/llvm-
| project/tree/main/mlir/examples...
| bruce343434 wrote:
| Can this handle undelimited continuations?
| remexre wrote:
| I thought you could implement those in terms of delimited
| continuations easily by making your top level the delimiter.
| pmatos wrote:
| That's something I have thinking about lately. It would be
| interesting to know if there's any prior work of implementing
| delimited continuations on MLIR.
| hgrergt wrote:
| [flagged]
| amir734jj wrote:
| What is the difference between MLIR and LLVM IR code that we used
| to?
| erichocean wrote:
| LLVM IR is just one IR _dialect_ in the MLIR ecosystem, and
| there are a bunch of (included) higher-level IR dialects that
| can be transformed (usually, automatically) into the LLVM IR
| dialect, and from there, the normal LLVM compiler can take over
| and produce runnable machine code.
|
| Your own languages can target the higher-level IR dialects in
| MLIR, or directly target the LLVM IR dialect, or both: MLIR is
| unique in that multiple IR dialects are allowed to be "live" at
| any time in the compiler, there are no strict "phases" where
| one IR is lowered, one-shot, into a lower-lever IR, like most
| compilers require (and compiler books teach).
|
| MLIR is a really, really neat bit of technology.
| Findecanor wrote:
| As I understand it, MLIR is the new subsystem that the LLVM
| project is transitioning to in the long term, and LLVM IR is
| the old.
|
| As such, LLVM IR isn't a proper subset of MLIR. Rather, there
| is a LLVM "dialect" in the MLIR system which can be
| translated 1:1 to LLVM IR.
|
| MLIR in its structure and textual syntax is a bit different.
| A "dialect" is more like a namespace for your ops than a
| different language, in my view.
| mathisfun123 wrote:
| >As I understand it, MLIR is the new subsystem that the
| LLVM project is transitioning to in the long term, and LLVM
| IR is the old.
|
| this is very much not a forgone conclusion and many people
| in LLVM would boo vociferously at the idea (see last year's
| LLVM US meeting where Johannes Doerfert actually argued the
| exact opposite - extending LLVM IR to do some/many of the
| things that MLIR does).
| comfypotato wrote:
| In the transition, traditional LLVM IR isn't being left
| behind. It's simply a later step in the compilation
| process. All MLIR is (eventually) translated through LLLVM
| IR before machine code.
| KingLancelot wrote:
| [dead]
| einpoklum wrote:
| I say programs are digraphs and any compiler/compiler-ish library
| which represents them as serialized textual statements (other
| than as the final backend output) is just doing it all wrong.
___________________________________________________________________
(page generated 2023-05-02 23:00 UTC)