Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!paperboy!snorkelwacker.mit.edu!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: Optimising C compiler question
Message-ID: <20715@lanl.gov>
Date: 9 Apr 91 15:58:08 GMT
References: <1991Apr8.193155.3911@vax5.cit.cornell.edu>
Sender: news@lanl.gov
Distribution: comp
Organization: Los Alamos National Laboratory
Lines: 58

In article <1991Apr8.193155.3911@vax5.cit.cornell.edu>, umh@vax5.cit.cornell.edu writes:
|> Something I wonder about.
|> C has provision for register variables, which are supposed to run faster than
|> standard variables. How come one never sees register variables in any code?

I see them all the time.  Most of my local variables in C code that I
write are register.  I wish it were the default mode for all automatic
variables.  According to the ANSI standard, the only thing that the
register attribute means is that you can't point to that variable (that
is, you can't use the 'address-of' operator (&) on them).  This means
that a smart compiler can optimize them is ways that it otherwise can't.

|> Are modern RISC compilers sufficiently good that they automatically make
|> sensible choice of register variables? [...]

No.  At least I've not seen any that good.  The problem is that _any_
use of the address of a variable requires turning off the register
atrtribute - even call by reference to a procedure.  Unless the compiler
keeps track of all uses of all variables, it can't identify those that
can be made register variables.  Most compilers optimize on the 'basic
block' level - and don't know much about the use of variables outside
that level (except for the declaraction).  Still, as you say, a _really_
good compiler would make the register attribute redundant.

|> [...]                          Can I make my code run slower by using
|> them?

Yes.  A low quality compiler might try to force your register variables
into real registers as often as possible.  Even this sort of behaviour
can be useful, but you have to choose your register variables very
carefully and knowing something about the target machine language
(and especially how many registers it has) is a prerequisite.  A better
compiler will simply make use of the no-alias property of register
variables and on those compilers you should make everything register
that you can.

|> [... nested scope ...]                Can judicious use of this speed
|> things up- the compiler should know it doesn't have to save i when it leaves
|> that block etc?

Yes and no.  An exceptionally bad compiler may actually do stack
allocation chores for each nexted scope.  This could mean, for example
that a variable inside the scope of a loop could cause memory management
calls for each pass through the loop.

Fortunately, most compilers only do stack accocation on entry to a
procedure and allocate enough for all nested scopes at that time.
However, most really good modern compilers will already know whether
a variable is 'live' on exit or not.  If you don't use the variable
anywhere else in the code, a really good compiler will not do any
redundant stores.  In fact, even if you _do_ use it elsewhere in the
code, but all paths to the additional use contain an assignment to the
variable, the compiler will still not do the store.  (Liveness analysis
is more often available than the global data flow required to identify
a variable which can be given register attribute.  I don't know why this
is, the same mechanisms could carry the additional information.)

J. Giles