But LLVM already has a lot of good backends (emscripten, arm, ppc, x86, amd64). Why reinvent the wheel when you could just make Go a LLVM frontend and be done with it?
That would be my hunch. I think it makes a lot of sense. Also, note that there is that project which exists : http://llvm.org/viewvc/llvm-project/llgo/
There can be a compile time hit, but you can use FastISel, which is not bad. The compile time hit is mitigated by the fact that you get a far, far more mature series of optimization passes. Since the Go compiler is itself written in Go, more optimizations would make the Go compiler itself faster, further reducing the performance impact.
> Flexibility over the backend ?
Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. This is what Swift, for example, is doing with SIL.
It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.
The other aspect is that the Go compiler is intended to be very fast. That's not an explicit design goal of llvm - using llvm would slow the compiler down although it would have other advantages.
In the meantime, Go still supports more hardware ISAs than LLVM. Apparently reinventing the wheel is much cheaper than adding wheels to the old car.