Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 16, 2012 6:27 pm wrote:
> 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.)

It's not just lack of load-op (and RMW) that makes ARM a big more register hungry, it's also the lack of large immediates and [reg + reg + imm] memory addressing. If immediates and constant memory locations are used a lot in inner loops they can be cached in registers outside of the loop. I often have several constant registers in tight inner loops in ARM ASM.

Three operand addressing pushes back against this a bit though.

I could also see more registers being useful in cases where predication makes sense, and is more available than it may have been on x86. For instance, merging the result of two small conditional arms with a select.

And with x86 you don't have to spend a register for return addresses; while this is often turned into a temporary after the register is saved on the stack it's nice to be able to keep it around in leaf functions (or ones which won't always call other functions anyway, which will sometimes be some of the more performance critical paths)

I do wonder what the exact context is for Mitch Aslup's figures. Is it an average over several types of designs, or does it only apply to high end very aggressively OoO chips? There has been some discussion here before about whether or not AArch64's register provisions were done with in-order chips in mind (to better facilitate software scheduling). The point was raised that lower end processors wouldn't need to be 64-bit any time soon, but if ARM's big.LITTLE topology proves successful then surely it'll get ported to ARMv8 within a few years. And in that case the little CPU is going to have to support whatever instruction set the big one does, and I'm sure it won't have anywhere near the reordering depth.

> 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).

SP is really kind of halfway between GPR and special register, which can be accessed as r31 for some fields in some operands - where it's otherwise a constant zero. This is IMO a pretty intuitive use of the register which I haven't seen before in any of the big RISCs, although PowerPC does have some repurposing of the field. Either way, with a similar instruction set but modified for only 4-bit register fields you'd still have only 15 GPRs given the same zero/SP register. So it'd at least be a bit below x86's allocation capability for 16 GPRs.