

New SSA Back End for the Go Compiler - rjammala
https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit?usp=sharing_eid

======
pcwalton
> Runtime information.[n] The runtime needs accurate maps of stack frames for
> both GC and stack copying, something that is not available from standard
> backends today.

This is now incorrect as far as LLVM is concerned. LLVM has experimental
support for late safepoint placement (contributed by Azul), which allows
copying GC and relocating stacks:
[http://llvm.org/docs/Statepoints.html](http://llvm.org/docs/Statepoints.html)

~~~
jevinskie
llgo is already a thing: [https://github.com/go-
llvm/llgo](https://github.com/go-llvm/llgo)

------
rayiner
If you're wondering what the heck SSA is:
[http://www.cs.rice.edu/~keith/512/2013/Lectures](http://www.cs.rice.edu/~keith/512/2013/Lectures).
Specifically this one:
[http://www.cs.rice.edu/~keith/512/2013/Lectures/11InfoChains...](http://www.cs.rice.edu/~keith/512/2013/Lectures/11InfoChainsToSSA-1up.pdf).
The folks at Rice have the most approachable material on program optimization
I've come across.

~~~
0xdeadbeefbabe
Is IR instruction representation?

~~~
Hemospectrum
Almost: _Intermediate_ representation. "Intermediate" because its primary
purpose is communication between different phases of a compiler in a
serializable form. Some compilers actually have multiple IRs for different
stages; for example, GHC will first turn Haskell code into "Core," followed by
STG, C--, and LLVM IR.

------
torrance
"A common question that comes up is “why not just convert to the IR of
{llvm,gcc,...} and go from there?” [...] I’m happy to be convinced otherwise -
maybe we should throw our effort into getting frame maps out of {llvm,gcc,...}
and figuring out how to configure the backend (e.g. which optimizations to
turn on) to make it compile quickly."

Wouldn't this be worthwhile just to be able to use some of the LLVM tools
(debuggers, performance analysers, etv.) alone? Not to mention optionally
being able to compile with more expensive optimisations.

~~~
jsd1982
LLVM and its tools are implemented in C++. The Go team just underwent a large
effort to remove their dependency on C code. A reasonable assertion can be
made that given this C code removal, a large and complex C++ dependency like
LLVM is unlikely to be in their sights for inclusion into the compiler.
Perhaps this wouldn't be an /entirely/ unreasonable to do; I can imagine a
`cgo` binding to LLVM existing for this purpose. Speaking of which, I wonder
what the fate of `cgo` is with this compiler code migration from C to Go.

~~~
andrewchambers
LLVM already has official go bindings in the main repo, also, the llgo go
compiler uses these bindings.

Unfortunately building it all was a pain for me, and the resulting binary was
80 megs which seemed a bit ridiculous (Go had to statically link all of llvm
into one monolith).

------
riobard
OT: every time a popular Google doc is shared I see this banner at the top
saying that "Wow, this file is really popular! Some tools might be unavailable
until the crowd clears." with the option to try again or dismiss the message.

I'm wondering what tools I am missing given that this is basically a read-only
view?

~~~
rictic
Google docs urls that end in /edit will try and figure out what rights you
have to the document and give you tools corresponding to those rights (to edit
the doc, to share it, to add comments, to add suggestions, etc).

Google docs that end in /preview just show the read-only view.

When a doc becomes super popular, sometimes /edit will redirect to /preview.

------
nulltype
Is a 10% speedup optimistic? I find it odd that the hand-optimized assembly
prototype had no detectable speed difference.

------
cornewut
I'm sorry, I misread it as "New NSA backdoor".

