Exophase (exophase.delete@this.gmail.com) on August 16, 2012 2:52 pm wrote:

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

Its true one can make use of a large number of GPRs in hand-written assembler, I've done a lot of assembler programming on 68k and while the 8 addresser register was often enough, having just 8 data register was often a limitation. I've also done some assembler optimizations for ARM and my handwritten functions definitely uses more GPRs compared to the code generated by GCC.

It has been suggested that the load/store nature of a RISC architecture will lead to usage of more GPRs compared to x86, but I cannot really see that when looking into code generated by compilers and registers are faster compared to pushing things to the stack even on the x86 so a optimizing compiler want to keep things i registers if possible.

So why isn't more register used in code generated by compilers. I looked at fairly large code-base and got this register usage

ARM.
Number of instructions that refers to any of the r0-r12 registers: ~170k
r10-r12 is not used
r4-r7 are all used 5-6k times
r8,r9 ~10k times
r3 16k
r2 23k
r1 38k
r0 69k

So it seems that there is "enough" register in every single case in this program.

I did the same thing on PPC and MIPS using mostly the same source code just to see what the compiler would do when there is more registers available. This source do include a small embedded OS-kernel and drivers so it is not a true apple-to-apple as the PPC card has more devices, hence will be bigger.

PPC
Number of instructions that refer to any register: ~300k
Every single register is actually used.
r2,r14-r18,r21-r23 are all used 1k-2k times
r8,r10,r12-r13,r19-r20,r24-r26 are all used 3k-6k times
r6-r7,r9,r27-r29 are all used ~10k times
r4-r5,r30-r31 are all used 20k-30k times
r1 65k
r0 81k
r3 85k

MIPS is similar, 4 of the temporary registers are used very sparsely while t0 and a0 are the most frequently used register (not too surprising).

Number of registers is something that people tend to bring up quite a lot and suggest more is always better. IA32 is often frowned upon because it has so few GPRs.

So to spin the question a bit: what are the downsides of a large number of GPRs? It has to be fairly big trade-offs to be made somewhere as very few architectures seem to move beyond 32 GPRs and AMD did for some reason settle at 16 GPRs when they designed x86_64. Not a perfect comparison, but the performance difference between IA32 and x86_64 is very small so IA32 cannot be held back too much by its lack of GPRs.

One point of reference to compare IA32 vs x86_64 is . Looking at the single core results for C and Java show that some things are faster and some things are slower on IA32, but the results are with very few exceptions VERY similar.

Sorry for a long post, interesting topic i.m.h.o :)