Available No. of Registers

Richard Mathews lcc.rich-wiz at locus.ucla.edu
Wed Jan 21 20:22:46 AEST 1987


> There is a false implication in the above: that it doesn't hurt to add
> register declerations. There is at least one compiler out there that
> effectively allocates registers from the last declared instead of the
> first, so that blindly adding registers to code can slow the generatred
> code down.

There is another more common case where excess register declarations hurt
performance.  Consider, for example, the VAX compilers distributed with
BSD and SYS V systems.	When a function is called the compiler will only
cause those registers to be saved which are actually "used" in the function.
All registers allocated to register variables are considered to be used.
If you declare a variable to be "register" and it is never accessed, you
have wasted a "push" of this register (even if the "push" is actually
built into the VAX's "calls" instruction).

If the variable is an argument, there is the added problem that the register
must be loaded with the argument's value.  This will be true on just about
any architecture.

Someone here at LOCUS once made the following recommendations.	Besides the
above, these take into account the fact that moving a pointer in a register
may give more of a performance gain than moving an integral variable into
one.  By "ref", this refers to the "typical" number of run time references
(whatever that means) rather than the number of syntactic references.  I
don't know that I agree with these numbers, but they are probably the right
order of magnitude for a lot of machines/compilers.  I'd probably make all
of these numbers a little lower.

	a. don't make a local pointer a register unless at least 3 refs are
		made
	b. don't make a parameter pointer a register unless at least 4 refs
		are made
	c. don't make a local integer a register unless 4 or 5 refs are made
	d. don't make a parameter integer a register unless 6 or more refs
		are made.
	e. be care to look for various forms of loops when doing ref counting.

Richard M. Mathews
Locus Computing Corporation		       lcc.richard at LOCUS.UCLA.EDU
					       lcc.richard at UCLA-CS
				 {ihnp4,trwrb}!lcc!richard
       {randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard



More information about the Comp.lang.c mailing list