We propose adding support for aggregate data in the stack reuse to the Go compiler. The Go 1.20 compiler cannot handle the local array effectively in the stack allocation. Consider an example as follows.

package simple type Field struct { Integer int64 String string Interface interface{} } func a(i int8) Field { return Field{} } func b(i int16) Field { return Field{} } func c(i int32) Field { return Field{} } //Simple does func Simple(i interface{}) Field { switch val := i.(type) { case int8: return a(val) case int16: return b(val) case int32: return c(val) default: return Field{}	} }

The corresponding disassembly is as below.

 0x01a5 00421 (simple.go:29)MOVQAX, command-line-arguments..autotmp_12+48(SP) 0x01aa 00426 (simple.go:29)MOVQBX, command-line-arguments..autotmp_12+56(SP) 0x01af 00431 (simple.go:29)MOVQCX, command-line-arguments..autotmp_12+64(SP) 0x01b4 00436 (simple.go:29)MOVQDI, command-line-arguments..autotmp_12+72(SP) 0x01b9 00441 (simple.go:29)MOVQSI, command-line-arguments..autotmp_12+80(SP)

In the example provided, it is evident that a distinct temporary stack variable is allocated to store the returned Field from the callees, ensuring that they do not share the same stack memory. However, this approach is suboptimal due to the live ranges of these variables are not overlapped. Each temporary occupies its own exclusive space, leading to the necessity of sharing the stack slot. To achieve optimal code, the allocation should only cater to the maximum size among all possible temporaries across all switch cases, rather than summing up their individual sizes.

Multiple compilers for C/C++ and other programming languages have the capability to reuse the stack for scalar variables and/or arrays. For instance, LLVM's stack coloring pass allows for the reuse of the stack memory for local arrays.

In summary, we propose adding stack reuse for aggregate data in the go compiler. Inputs are welcome.