name99 (name99.delete@this.redheron.com) on November 17, 2012 6:37 pm wrote:
[snip]
> Let's answer slightly differently.
> If you have a modern type of CPU (OoO, superscalar, prediction, all that good stuff) then there is a distinction
> between the number of PHYSICAL registers and the number of ARCHITECTED (ie expressible in assembly language)
> registers. The number of physical registers is going to be determined by how aggressively OoO you want your CPU
> to be, and it is the number of physical registers that determines power, area, cycle times and so on.
>
> Given this, the number of architected registers is essentially free. Going from 16 to 32 costs you
> an extra bit in each register specification (so 3 bits in most instructions) and that's it. If there
> is any advantage to increasing the number of architected registers, you might as well do so.

In an OoO implementation, one will also have a renaming table in the front end (and often one for commit as well, but that table has lesser requirements). Increasing the size of this table will increase power use and may complicate pipelining.

In addition, with a large number of architectural registers (with an implicit flat organization) many registers may be relatively idle but consume the same static power and increase the area of the register file (and so the latency and power of all register accesses).

Scalability of an ISA is also important. A large (flat) architectural register file will be less friendly to smaller implementations. (Such will also be less friendly to multithreading.) A 64 GPR ISA would require 33% more physical registers for GPRs than a 32 GPR ISA with 64 rename registers (which could satisfy an 80 instruction window in many cases). (There are also techniques to reduce the number of physical rename register required which do not apply as much or at all to architectural registers, e.g., virtual physical registers.)

> A second way to think about this is in terms of this as a "power" feature, like vector instructions, that will
> be used by people who know what they are doing, and not otherwise. For example: people who know what they are
> doing, on entry to a function, IMMEDIATELY load into a local (ie register) variable all globals that will be
> accessed, along with everything that will be used through a pointer. They do all their calculation in the local
> variables, then store everything on exit from the function. This style of coding requires a lot more registers
> to work with, but is also faster. (It's faster because it gets load latency off the critical path, and because
> it doesn't waste cycles doing things the compiler thinks might be necessary --- writing back globals, writing
> back instance variables --- but which you know are not, every time they are changed.)

In general high level language code will not express register allocation. With the increased interest in interprocedural and whole-program optimization, compilers should be fairly well equipped to exploit more registers.

It should also be noted that loading all registers at the start of a function may well not be an optimization. Even with an OoO implementation, distributing memory accesses through code tends to be more execution friendly.

> Why isn't the code you profiled showing this sort of thing? The cruel answer would be that there are just
> not that many people in the world who know what they are doing. A second alternative, which might be partially
> true, is that the bulk of programmers, and the bulk of code written, grew up with IA-32, not even x64,
> where this type of programming is not much of a win because of the paucity of registers. Ideally this will
> change, but we all know that it takes a generation or more for certain habits to die.

Or the bulk of code is written in a C-like language (with aliasing issues) and written for the ease of programming (at minimum writing, more ideally for ease of maintenance).

> Which gets back to my point. Plough-the-fields code will tend not to use half those registers, just
> like it doesn't use multi-threading or NEON. But performance critical code WILL use these features.

Compilers are becoming more sophisticated in autovectorization and register allocation may be an easier and more mature optimization. Autoparallelization is also becoming more common for certain types of programs.