Hacker News Reader

Comment by fintler | Hacker News Reader

Just a guess: it's probably static single assignment for the IR.

https://www.cs.cmu.edu/~fp/courses/15411-f08/lectures/09-ssa...

It appears it's a new way to do code generation. So any adding of new architectures is dead in the water until this is resolved.

https://groups.google.com/forum/#!topic/golang-dev/zz-gWGXFZ...

Actually, the opposite. The merging of the branch means that people are now free to continue work on adding new architectures.

Did the compiler get even slower on tip? I know that was a concern with this change

10% slower, which isn't too bad, let's hope they can now focus on improving compilation speed, I miss go 1.4 having recently upgraded. It would be really nice to see that actually improve for 1.7 instead of regressing.

SSA, once you understand it, is easier to work with than almost all other forms of instruction sets. I'd argue that it would only accelerate new architecture in the long-run.

I'm interested in why LLVM was disqualified. Was it simply never considered or is it incompatible with the Go type system, calling convention, etc.?

It's rather easy to add a calling convention to LLVM. If I would have to guess it would be that they thought LLVM was too slow for them. They said from the start compilation speed was a big point for them.

Also LLVM requires you to either write your IR in SSA or add another expensive optimisation pass to make it SSA (mem2reg). Perhaps they thought writing an SSA generator would be too much of a headache.

The LLVM docs say that clang uses mem2reg for mutable local variables, so it can't be very slow.

From the end of

http://llvm.org/docs/tutorial/LangImpl7.html#memory-in-llvm

> Proven and well tested: clang uses this technique for local mutable variables. As such, the most common clients of LLVM are using this to handle a bulk of their variables. You can be sure that bugs are found fast and fixed early.

> I'm interested in why LLVM was disqualified.

They simply used what they knew best:

> If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two.

> Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly I'd probably have left the project years ago.

https://news.ycombinator.com/item?id=8817990

Even today we can still re-build the entire tool chain and standard library in one minute on a modest machine.

If we were using LLVM...

In addition to what others said, support for precise garbage collection in LLVM was not ideal at the time. The experimental gc statepoint extension spearheaded by the Azul guys is trying to change that. They've been working on it publicly since late 2014.

Reply on news.ycombinator.com