|[10 earlier articles]|
|Re: register variables in C. firstname.lastname@example.org (1992-05-01)|
|Re: register variables in C. email@example.com (1992-05-01)|
|Re: register variables in C. firstname.lastname@example.org (1992-05-02)|
|Re: register variables in C. email@example.com (1992-05-04)|
|Re: register variables in C. firstname.lastname@example.org (1992-05-04)|
|Re: register variables in C. email@example.com (1992-05-04)|
|Re: register variables in C. firstname.lastname@example.org (1992-05-06)|
|From:||email@example.com (Cliff Click)|
|Keywords:||C, registers, optimize|
|Date:||Wed, 6 May 1992 16:48:35 GMT|
Gregory Bond <firstname.lastname@example.org> said:
> email@example.com (Gene Ressler) said:
> > In this context, it seems more appropriate to have programmers tag uses
> > of variables rather than declarations.
> The problem with this (inherent in any scheme, including "register", that
> focuses on source language variables) is that the really chunky bits are
> hidden from the programmer (such as common subexpressions, address
> arithmetic etc); such schemes don't help compilers much when making
> decisions about these hidden entities.
With tricky loop restructuring techniques commmonly used in vectorizing or
parallelizing compilers it becomes VERY difficult for the programmer
determine what belongs in a register, and when.
> I'm not really a compiler weenie; what is the current state of the art
> w.r.t. discovering branch possibilities or loop frequencies? Do compilers
> routinely differentiate between "for (i = 1; i < 3; i++)" and "for (i = 1;
> i < 300; i++)" or similar constructs?
Compilers for supercomputers routinely distinguish between such loops
(i.e. the 3 iteration loop being a candidate for unrolling). Also the
live range of variables are often split around loops, so that variables
are kept in registers in the loop, but perhaps in memory outside of the
PC compilers are now doing constant propagation and loop-invariant code
motion, but aren't (that I know of) splitting live ranges up to avoid
loads inside of loops. This could be a big win on machines with few
I'm not familiar with the quality of workstation compilers; I use gcc 2.1
which looks to do about the same as the PC compilers.
Return to the
Search the comp.compilers archives again.