compiler: port big Go escape optimization pass

[eliasnaur]

In my quest to remove heap allocations that big Go doesn't incur (most recently #4576), I realized that it may be advantageous to outright port big Go's escape pass (https://github.com/golang/go/tree/master/src/cmd/compile/internal/escape) instead of playing whack-a-mole. The main advantage apart from improved escape analysis is fewer (or zero) heap allocation differences between the Go implementations.

I can look into it, but I want to raise this issue in case more experienced tiny-gophers see fundamental issues. For example, if you'd rather improve or enable LLVM optimization passes (@aykevl mentioned this on #4512 (comment)).

[aykevl]

I'm not really convinced this is going to work well, because the compilers are so very different. Also because the most interesting heap-to-stack transforms are going to happen after a ton of other passes have run (especially the inliner), possibly as part of the ThinLTO linking part. Doing these optimizations as part of the passes written in Go probably wouldn't get us very far, for example cases like #4512 would be difficult to implement as a Go pass early in the optimization pipeline.

Also, I have a long term goal of removing the whole-program optimization passes in transform.Optimize because having these whole program passes (instead of passing the bitcode of each individual package to the ThinLTO linker) is a big reason why the compiler is so slow at the moment.

I'd first like to see how far we can get with the Attributor HeapToStack pass, and if that one doesn't catch all cases we care about we can look into other options.

[eliasnaur]

Alright, I'll close this is favor of the LLVM route.

(FWIW, I would expect big Go's escape.go pass to be per-function/package and therefore compatible with ThinLTO).