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....

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?

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.

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.

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

Has the video for this already been released? I just checked llvm.org but wasn't able to find it.

Thanks!

No, videos aren't out yet.

Link to video of presentation: https://www.youtube.com/watch?v=Ntj8ab-5cvE

Very nice. I particularly like the basic block arguments. Huge improvement over phis.

edit: I would have been very interested to see perf with SIL opts turned off - to see how well LLVM can do without SIL optimizing before it.

Yeah, the basic block arguments are nice. The one thing that would complicate their use in a low-level IR is that they are awkward in cases where you want to pass different arguments to different successors. If you don't want every control-flow transfer instruction to pass additional per-target args then you have to split edges, but you may have edges that you can't or don't want to split.

Interesting, forgive my ignorance, but does this mean anyone could write a language that compiles to SIL and then to LLVM IR?

SIL isn't open-source to my knowledge, so no. Maybe once/if Apple open-sources Swift, though? (They claim they will do that later this year.)

Basic blocks with arguments seems similar to the scheme (hah!) used in the Twobit compiler: http://dl.acm.org/citation.cfm?id=156786&dl=ACM&coll=DL&CFID....

So I'll ask the question: do this mean we're getting anywhere close to getting Swift to compile to other backends?

I believe RemObjects[1] has already implemented a 3rd party Swift compiler. So technically, they have compiled Swift using a non-LLVM backend.

1: http://www.elementscompiler.com/elements/default.aspx

It's a little frightening that they talk about reimplementing Swift and reusing code and all that, then if you dig deeply enough you find that in their language, collections and strings are reference types, not value types. That's a huge difference and makes their language decidedly not Swift.