preston@titan.rice.edu (Preston Briggs) (02/07/90)
In article <PCG.90Feb5185112@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <4467@brazos.Rice.edu> I wrote: > manually insert vector primitives. Register allocators are > good enough that I need not scatter register declarations about. > >About the "good enough" I am somewhat skeptical (especially about >the register allocators -- but then again, many modern machines >have more registers than variables...). Some modern machines can compete with small subroutines, most (80x86's, 680x0's) can't. You oversimplify when you imply that a register allocator works only with a routine's variables. A fair portion of the problem arises from temporaries generated during translation, even without optimization. With optimization, the problem grows. Generally I'd guess that a hefty register allocator is a waste without optimization -- no grist for the mill. I suppose it's possible in C to write code that needs no temporaries; but what a pain! No expressions with more than one operator and the operands can only be trivial. > Constant propagation is strong enough so that I can afford >This is *not* an optimization. It does not involve second >guessing the program's semantics. It is just good code >generation. Like removing redundant code, inlining, reordering >expression's operands (where allowed by language rules), etc... I meant more than simple constant folding. I mean across the entire routine, complete with data flow and def-use chains and other optimizer goodies. It's a significant problem and cannot be simply dismissed as "just good code generation". On the other hand, I'm suprised that you consider inlining to be "just good code generation." Most (many?) optimizer people think inlining is a hard problem. Currently, I'd say it's a candidate for Jim Giles list of transformations (better than "optimizations") to be specified by hand since nobody knows how to make the compiler do it right. (By right, I mean profitably. Correctly is (fairly) easy.) Preston Briggs preston@titan.rice.edu