I may have missed it, but this discussion seems to be lacking a key motivation of go. That is, the go devs have preferred a fast compiler over fast code output.
I have a hard time imagining them adding a bunch of optimizations around code generation when those optimizations will almost certainly:
* Slow down compile times
* Increase compiler complexity
* Be worse than what something like LLVM would produce.
Maybe it makes sense to integrate a "release" build which targets LLVM? IDK. But I do know that so long as compilation speed is a major goal for the language the you simply won't see optimizations being seriously considered.
The short answer is that there are optimizations that the GC is doing which gccgo is not doing.
The long answer is that gc will do escape analysis which can avoid allocating on the heap, gccgo doesn't do that.
Why might LLVM be better suited? Primarily because the framework also supports JIT and has efforts from the likes of Azul to make their JVM faster. Most optimizations that would benefit Java will benefit go.
I have a hard time imagining them adding a bunch of optimizations around code generation when those optimizations will almost certainly:
* Slow down compile times
* Increase compiler complexity
* Be worse than what something like LLVM would produce.
Maybe it makes sense to integrate a "release" build which targets LLVM? IDK. But I do know that so long as compilation speed is a major goal for the language the you simply won't see optimizations being seriously considered.