Actual modern x86 implementations have hundreds of registers; what they are starved for is register names. This puts enormous pressure on the register-rename and reordering logic of the processor, but Intel and AMD have turned out to be quite good at delivering there, to the point that (certain numerical algorithms aside) the relative lack of register names is usually a non-issue.
More precisely, it's the compiler (or luckless .asm hacker) that suffers from register starvation. Register renaming can avoid pipeline blockage but if the compiler thinks it's out of registers, it'll use... wait for it... memory accesses. Now you've entered the wonderful world of load/store penalties and the like, and at least some of those cache lines that the Mozilla folks wanted to preserve are going to get used anyway.
It's really a pretty terrible idea for Mozilla to favor 32-bit code over 64-bit code these days. Not so much because of any feature or perf differences, but because it signals that they don't really have a clue what they are doing.
As a lucky asm hacker and frequent advisor to compiler codgen engineers, in the past few years re-order engines have gotten to be wide enough that it's really not too bad. It simply requires a different mindset; instead of attempting to hand-schedule individual instructions, one instead schedules small blocks of instructions chosen to minimize state that must be preserved across block boundaries (to minimize register usage between blocks) and lets the rename/reorder do their work.
There are some (mostly numeric -- hand-tuned FFTs come to mind) codes for which the lack of names really does cause difficulty, but they are relatively few and far between.
All that aside, yes, 8 GPR names is just absurd, and targeting x86_32 is ridiculous when x86_64 is so widely supported.
