Register Allocation in the Go Compiler

developers.redhat.com

69 points·jnord··10 comments

Really appreciate the article and the pointer to Go's SSA backend, which appears to implement common optimization passes like SCCP succinctly with good comments[0]. It's always nice to see harder concepts implemented with simplicity and readability in mind.

[0] https://github.com/golang/go/blob/master/src/cmd/compile/int...

Nice write up. I admire the author's work in general.

I wrote a little more about critical edge splitting and out-of-SSA:

https://nickdesaulniers.github.io/blog/2023/01/27/critical-e...

I thought that because GoLang has an LLVM backend, that register allocation was handled by LLVM itself?

Go's backend is custom.

They consider LLVM too slow and made their own.

https://github.com/go-llvm/llgo is third party and archived.

After trying Rust for a while, maybe they’re right. One of the reasons I don’t think I could work with Rust is that Go has spoiled me with fast compile times for so long.

gccgo supports dynamic linking and foreign functions, and allegedly generates better-optimized code. The default compiler can share OS threads between goroutines, but not other languages (I guess stacks are no longer segmented but they could be copied?)

Good explanation why Go's compiler sucks on some/most cases (with lot of If's).

Who thought it was a good idea to have scrolling change the page history?

On a Red Hat site no less. Man, they really are taking a tumble.

Jeepers! That is horrific.

Reply on news.ycombinator.com