Hacker News Reader

Comment by steveklabnik | Hacker News Reader

This is really interesting, Rust is also moving to a similar system, though we have two:

    AST -> HIR  -> MIR -> LLVM IR -> binary

The higher-level IR and mid-level IR are being introduced for the same reasons as this presentation, basically. It looks like SIL is closer to MIR.

HIR: https://github.com/rust-lang/rfcs/blob/master/text/1191-hir....

MIR: https://github.com/rust-lang/rfcs/blob/master/text/1211-mir....

View on HN

It seems a shame that all these different users of LLVM are having to do their own IR. Tools like RPython and Truffle don't seem to need language-specific IRs to perform well. Why does LLVM? Could it at least be made into a single shared LLVM-IR project?

A high-level IR implements the semantics that the programming language provides. You can only share it if the semantics are reasonably compatible.

This would be akin to asking why do we need a C++-specific AST and a Swift-specific AST.

Right, but as I say RPython and Truffle manage without.

RPython and Truffle essentially derive language-specific IRs from a specification of an interpreter, with RPython using meta-tracing and Truffle using traditional partial evaluation.

RPython's technique also only works for JITs, and neither Swift nor Rust use a JIT in their normal compilation pipeline. Generation of compilers by partial evaluation of an interpreter is interesting, but as far as I know it has never been used in an industrial strength implementation of a language.

If you use RPython you implement a language-specific interpreter and get a JIT for free. It's a completely different world, but it's no free lunch.

It would be really interesting to compare SIL to Rust's HIR/MIR and the graph-based IR Sebastian Hack's group published a paper on at CGO this year http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf

Reply on news.ycombinator.com