Okay. I guess at first it’d help to describe what the old compiler was like. The old compiler used to take the abstract syntax tree of a Go program and would generate code sort of node-by-node on that syntax tree. If there was a plus, it would load both arguments into registers, do the plus and then store the result somewhere.
[00:04:02.17] It would do that one at a time on the nodes of the syntax tree, with no look ahead, very little look behind… The code it generated wasn’t very good, because there were a lot of moves you didn’t need, there were a lot of operations that if you did that same add twice, it would execute that add twice instead of reusing the result.
So SSA instead takes the abstract syntax tree and builds a control flow graph, and a value graph. And then we can do all sorts of optimizations on that graph, like common self-expression elimination, we can do bounce check elimination, we can do better scheduling, dead code elimination, all that sort of stuff – all of which benefit the generated code and make it better than what was generated previously straight from the abstract syntax tree.
SSA compilers have been around for a while. I know I’ve worked on one 15 years ago, so it’s a pretty mature compiler technology. GCC uses it, LLVM uses it… It’s a pretty common compiler technology. This is not sort of a researchy thing; SSA is known to be a good way to generate code for compilers. We need to get Go up to speed so that we can compete with the other languages.