Compilers and IRs: LLVM IR, SPIR-V, and MLIR

https://www.lei.chat/posts/compilers-and-irs-llvm-ir-spirv-and-mlir/

by matt_d • 4 years ago

111 29 4 years ago

thechao2• 4 years ago

I have an irrational dislike of SPIR-V. On the flip side of the coin I think MLIR is a work of genius — especially as a springboard for ideas in developing custom IR.

fooker3• 4 years ago

MLIR is also siloing compiler research and development.

Every one and their mother has their own proprietary MLIR dialect nowadays, and the era of competitive open source compilers is sort of fading.

trogdc3• 4 years ago

They probably would have their own proprietary "something" anyways, if not MLIR.

delta_p_delta_x• 4 years ago

I have an irrational dislike of SPIR-V

Out of curiosity, why?

imtringued• 4 years ago

Games ship with source based shaders. SPIR-V basically means games ship binary shaders.

thechao2• 4 years ago

I … don’t know? Originally, it just felt like some janky subset of LLVM-IR: close enough to almost work with the standard tooling, right out of the box, but not quite. It’s been nearly 10 years since I’ve looked at it, though, so what do I know? I don’t even know if they kept the design I was shown.

k4st2• 4 years ago

At Trail of Bits, we are creating a new compiler front/middle end for Clang called VAST [1]. It consumes Clang ASTs and creates a high-level, information-rich MLIR dialect. Then, we progressively lower it through various other dialects, eventually down to the LLVM dialect in MLIR, which can be translated directly to LLVM IR.

Our goals with this pipeline are to enable static analyses that can choose the right abstraction level(s) for their goals, and using provenance, cross abstraction levels to relate results back to source code.

Neither Clang ASTs nor LLVM IR alone meet our needs for static analysis. Clang ASTs are too verbose and lack explicit representations for implicit behaviours in C++. LLVM IR isn't really "one IR," it's a two IRs (LLVM proper, and metadata), where LLVM proper is an unspecified family of dialects (-O0, -O1, -O2, -O3, then all the arch-specific stuff). LLVM IR also isn't easy to relate to source, even in the presence of maximal debug information. The Clang codegen process does ABI-specific lowering takes high-level types/values and transforms them to be more amenable to storing in target-cpu locations (e.g. registers). This actively works against relating information across levels; something that we want to solve with intermediate MLIR dialects.

Beyond our static analysis goals, I think an MLIR-based setup will be a key enabler of library-aware compiler optimizations. Right now, library-aware optimizations are challenging because Clang ASTs are hard to mutate, and by the time things are in LLVM IR, the abstraction boundaries provided by libraries are broken down by optimizations (e.g. inlining, specialization, folding), forcing optimization passes to reckon with the mechanics of how libraries are implemented.

We're very excited about MLIR, and we're pushing full steam ahead with VAST. MLIR is a technology that we can use to fix a lot of issues in Clang/LLVM that hinder really good static analysis.

[1] https://github.com/trailofbits/vast

erichocean• 4 years ago

LLVM dialect in MLIR, which can be translated directly to MLIR

Should be:

LLVM dialect in MLIR, which can be translated directly to LLVM IR

Otherwise, great project! We're also using MLIR internally and it's been awesome, game-changing even when considering how much can be accomplished with a reasonable amount of effort.

k4st2• 4 years ago

Typo fixed! Thanks :-)

I think the next big problems for MLIR to address are things like: metadata/location maintenance when integrating with third-party dialects and transformations. With LLVM optimizations, getting the optimization right has always seemed like the top priority, and then maybe getting metadata propagation working came a distant second.

I think the opportunity with MLIR is that metadata/location info can be the old nodes or other dialects. In our work, we want a tower/progression of IRs, and we want them simultaneously in memory, all living together. You could think of the debug metadata for a lower level dialect being the higher level dialect. This is why I sometimes think about LLVM IR as really being two IRs: LLVM "code" and metadata nodes. Metadata nodes in LLVM IR can represent arbitrary structures, but lack concrete checks/balances. MLIR fixes this by unifying the representations, bringing in structure while retaining flexibility.

wumpus2• 4 years ago

Is reusing tool names in the same sub-field of Computer Science becoming a thing? VAST was a Fortran preprocessor.

wumpus2• 4 years ago

Good timing: just got an invite to attend VAST's breakfast discussion at the SC (supercomputing) conference.

HN: two net downvotes for asking a question.

CalChris• 4 years ago

How is this different from Facebook's CIR?

https://www.phoronix.com/news/Meta-Developing-Clang-IR-CIR

boundchecked• 4 years ago

I'm also curious, especially they seem to be gearing towards analysis as well.

https://github.com/llvm/clangir/blob/main/clang/lib/CIR/Dial...

manv1• 4 years ago

Funny that there was no mention of GCC, since it was probably one of the first IRs that anyone encountered IRL. If I remember correctly one motivation for Clang/LLVM was because GCC's IR was so bad.

I knew people that wrote backends for gcc, and they pretty much all agreed it was a nightmare.

pjmlp3• 4 years ago

One of the first IRs was the PL.8 compiler, and the Amsterdam Compiler Toolkit, both predate GCC for quite a while.

vkazanov2• 4 years ago

I think advanced fortran compilers already used IRs by late 60s, early 70s.

Most compilers in the 80s already used some form of non-ast IRs: Generalised portable instructions, cfg representations, etc. I'd say that back then people were experimenting with various forms of IRs for optimization purposes.

By 90s it was typical for compilers to have several IRs. Gcc belongs to this compiler generation.

2000s is the time when IRs standardised around 2-3 SSA-like forms, which made it possible to do most optimisation work on this level only.

mamcx2• 4 years ago

MLIR sound interesting, but look like is totally dependant's on C++?

One of the problems of the article is how many compiler infra is re-made. But a big reason is that if you are doing Python, for example, you don't wanna touch C++.

In fact, nobody wanna touch C++, except(maybe!) C++ devs :)

pjmlp3• 4 years ago

One of the first customers of MLIR is the Fortran compiler for LLVM.

I only do Python when doing systems programming in UNIX that outgrow bash scripts, or scritping software that uses Python as their scripting language.

Then again, I enjoy using C++ despite its flaws. :)

TazeTSchnitzel2• 4 years ago

LLVM IR is usable from any language with a C ABI, Python included. There are bindings for various languages built on its C interface, e.g. OCaml.

mamcx2• 4 years ago

I know about LLVM, but MLIR? Is the same?

And for the look of it, look like is not something that is viable to do without using C++?

slooonz• 4 years ago

Shower thought: we need a SQLIR, to be able to communicate with databases on a lower level that SQL. Many ORMs would benefit for that.

Compilers and IRs: LLVM IR, SPIR-V, and MLIR

Related Stories