Kenneth Jonsson (kj.delete@this.localhost.org) on August 16, 2012 2:35 pm wrote:
[snip]
> More register does increase the cost of switching context, so unused
> register cannot be a good thing.
>
> So what are the benefits of moving to 32
> GPRs on ARMv8 from the current number of 16 (well 14 if one exclude PC and LR)?

Based on a (29 Jul 2012) post on comp.arch by Mitch Alsup (a computer architect who worked at AMD, Motorola, etc.):

BTW, the advantage of 16 registers in x86 over 8 registers is
on the order of 13%*, the advantage of 32 registers over 16 is
only 2%-3%. And once you were using REX bits for registers
all files could expand simultaneously.

Mitch
(*) Whether that 13% is realized in compiled code is not my=20
problem.

(Message-ID: )

As David Kanter noted, ARM's load-store nature would presumably modestly increase the benefit of more registers. Presumably some loop-rich workloads could also benefit from more registers (for unrolling and software pipelining). (I vaguely recall some paper from IBM indicating that some FP workloads had loops with some register spilling due to register pressure even at 32 registers. If one uses the same fields for FP/SIMD and GPR register names, having a 5-bit field could be appropriate.)

As an additional data point, the IBM zSeries added high register instructions to effectively separate 64-bit registers in two 32-bit registers. This indicates that 16 registers (even with memory-register operations) might not be "enough".

Discussions on comp.arch hint that the register translation array (Register Alias Table) is a more significant issue (for OoO implementations) than context switch overhead.

It might also be noted that AArch64 moves the stack pointer and PC into a special register space while the link register is a GPR (and there is a zero register).