Kenneth Jonsson (kj.delete@this.localhost.org) on August 16, 2012 2:35 pm wrote:
> I have never developed a compiler, but looking at code generated by GCC for ARM,
> x86_64, MIPS and PPC begs the question: is there really any real benefit in
> having more than 16 GPRs? I cannot really see that the 16GPRs that ARM and
> x86_64 has is a limitation in close to 100% of the functions, a large number of
> the functions uses less than 8 registers. This is also true on PPC and MIPS
> where 32 GPRs are available, most register seem to just sit there
> unused.
>
> 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)?

In hand-written assembly code I've come across many circumstances where performance would be higher with more than 15 GPRs. Sometimes this is only to accommodate scheduling in the absence of OoO, which shouldn't be the situation for at least the first launching ARMv8 platforms. I don't have information on how well compilers do, but I'm sure ARM has investigated this. Although perhaps more with their compiler than GCC, which even today is producing tangibly higher performance code. It's partially a question of how aggressive inter-function optimization is.

One area where ARM is certain to benefit is CPU emulation. It's much easier to do it when you have substantially more registers than what you're emulating (x86-64 would be one of the most significant considerations), since you then don't have to worry about register allocation at all and can keep more helper variables in registers.

The context-switch overhead seems more like the non-issue. Tell me if I'm mistaken in this, but my perception is that this demand hasn't really gone up over the years, if anything it has gone down (for instance Linux becoming tick-less), while cycles/second has gone up tremendously. I can't imagine needing more than a few thousand context switches a second at the most.