Re: register variables in C.

Eric writes and John comments:


> In general, can a good optimizing C compiler do a better job
> of assigning registers to variables better than the programmer?
>
> In other words, should a programmer ever use the "register" storage class?
> [My impression is that the compiler can do a much better job, particularly
> with a graph coloring register allocator, but I'd be interested in some
> real data. -John]


Since most compilers do the costing analysis for determining which
processor resources (i.e. registers) get assigned when, this analysis can
break down when faced with real dynamic runtime program execution. The
static analysis usually done by traditonal optimizers attempts to model
the dynamic use as best it can, but it is only a model. It can, no matter
how sophisticated it is, model a program's dynamic behavior wrong.


J. Eliot Moss writes:


> [compilers use static rather than dynamic frequencies, which can be
> misleading]


My favorite horror story was a Unix device driver that we were developing
for the early NCR TOWER series systems. In the interrupt handler, the
most common path was simple and short - determining that the IO worked and
that no further analysis is needed. Most of the code (90%) was specific
stuff to check for error conditions and retry the IO.


In this case, static costing looked at the code and weighed everything in
the procedure as equal, special casing code nested in loops and if's and
the like. The end code generation was worse that if no registers were
assigned, as all of the machine registers were used and needed to be
saved/restored within the common path even though this code didn't need
them. But this is the best that can be done with static analysis.


We are looking into using profile data to give us dynamic cost feedback
for driving optimization. This should help us focus the resources where
they are really used, if our profile run reflects actual use. We expect
that this will make significant improvements in the use of the CPU's
resources for cases where we can gather the profile data before fully
optimizing.


Another issue here came up in our recent SVR4 port using the MetaWare High
C compiler. In most PCC implementations that do assignment of registers,
if the coder specified the 'register' qualifier in a declaration then the
register was assigned to this variable if a register was available. Left
over registers were then assigned based on use/cost analysis. This
permitted a knowlegable user who knew the dynamic use of a variable to put
it in a register, even if staic use/cost analysis didn't see it that way.


High C took this 'feature' away as it's use/cost analysis does not honor
the 'register' qualifier. We wondered if this wasn't a bad idea,
especially in the Unix kernel where our developers have been used to
tuning the code with knowlegable use of the 'register' qualifier.


To summerize, static analysis only models the dynamic runtime environment
when determining how to spend the CPU's resources. In most cases it is
appropriate, but in some the model may no reflect actual dynamic use and
may cause bad choices to be made. Profile driven optimization should
improve the model with dynamic runtime feedback, as would honoring
'register' qualifiers in the source code.
--
Dave Howell (803) 791-6818
Compiler Technologies Group dave.howell@ColumbiaSC.NCR.COM
NCR Corporation
E&M - Columbia
3325 Platt Springs Rd
West Columbia, SC 29169
--

Return to the comp.compilers page.
Search the comp.compilers archives again.