
Swift Intermediate Language: LLVM conference slides [pdf] - tambourine_man
http://llvm.org/devmtg/2015-10/slides/GroffLattner-SILHighLevelIR.pdf
======
steveklabnik
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....](https://github.com/rust-
lang/rfcs/blob/master/text/1191-hir.md)

MIR: [https://github.com/rust-
lang/rfcs/blob/master/text/1211-mir....](https://github.com/rust-
lang/rfcs/blob/master/text/1211-mir.md)

~~~
chrisseaton
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?

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

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

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

Thanks!

~~~
bla2
No, videos aren't out yet.

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

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

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

~~~
rntz
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.)

------
rayiner
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...](http://dl.acm.org/citation.cfm?id=156786&dl=ACM&coll=DL&CFID=726500188&CFTOKEN=19122280).

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

~~~
kevinchen
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](http://www.elementscompiler.com/elements/default.aspx)

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

