baum@Apple.COM (Allen J. Baum) (01/08/91)
[] What I said was: >What I was arguing was that cache is not a substitute for more regs., although >marketing benchmarks and numbers might make it appear so. I thought I'd better add a caveat: More registers up to some limit. I'm not sure where the limit is, and that limit changes with compiler technology. Right now, it seems to be (very roughly) around 32- I'm willing to be corrected. At some point, better register allocation algorithms might push that higher. It is a bit of a chicken & egg problem. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
preston@ariel.rice.edu (Preston Briggs) (01/08/91)
In article <47823@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: > >I thought I'd better add a caveat: More registers up to some limit. >I'm not sure where the limit is, and that limit changes with compiler >technology. Right now, it seems to be (very roughly) around 32- I'm >willing to be corrected. At some point, better register allocation >algorithms might push that higher. I think this is mostly correct. However, I'd say that improved optimization tends to increase the number of registers required. Better register allocation tends to reduce the number of registers required. Again, we need caveats. Sloppy strength reduction can require more registers than careful strength reduction. Good constant propagation and dead code elimination require less registers. There are also other limits. For floating-point code, there no improvement to be had once the FPU is 100% busy. On many machines and many problems, it doesn't take too many registers to achieve this goal. Preston Briggs