> In fact, you might even consider not allocating a register greedily. What might that look like? I have no idea.
One case I'm aware of: if your ISA supports arbitrary memory operands like x86, rarely-used variables can be operated-on entirely on the stack. Historically this was something ICC did better than GCC, though it became much less relevant with the shift to 64-bit bringing more registers.
Most x86 instructions only support one memory operand so you can’t completely avoid register allocation. It isn’t a full-on hardcore CISC like 68k or VAX.
> In fact, you might even consider not allocating a register greedily. What might that look like? I have no idea.
One case I'm aware of: if your ISA supports arbitrary memory operands like x86, rarely-used variables can be operated-on entirely on the stack. Historically this was something ICC did better than GCC, though it became much less relevant with the shift to 64-bit bringing more registers.
I found this especially nice working with large SIMD constants.
Most x86 instructions only support one memory operand so you can’t completely avoid register allocation. It isn’t a full-on hardcore CISC like 68k or VAX.
Another great overview of Go compiler's register allocation: https://developers.redhat.com/articles/2024/09/24/go-compile...