The & (address) operator and register allocation

Tim Olson tim at crackle.amd.com
Sat Dec 3 06:10:24 AEST 1988


In article <1224 at cps3xx.UUCP> rang at cpswh.cps.msu.edu (Anton Rang) writes:
| I was thinking about RISC machines, and other machines with a lot of
| registers, and came up with a question.  Since the C language doesn't
| have call-by-reference, is it possible to allocate variables which are
| passed by reference into registers?
|   For example, the C code:
| 
| 	scanf("%d", &N);
| 
|   would require that the address of N be taken to read it from the
| standard input.  If I then have a loop:
| 
| 	for (i=0; i<N; i++) { ... }
| 
| would the final program have to read N from memory each time? Or does
| the C standard provide that some keyword (like 'volatile') be used to
| avoid possibly unsafe optimizations (like moving N into a register in
| the above example--the address of N could have been saved in scanf() ).

On most RISC machines (CRISP is the only exception I can think of, but
then it doesn't really have registers), taking the address of a local
variable results in that variable residing in the memory stack rather
than registers.  However, it is not necessarily the case that the
variable has to be read from memory if it is used in a loop.  If there
are no function calls or stores through pointers in the loop, then a
compiler is free to cache the value of the variable in a register. 
However, it normally must re-read the value from memory each time if
there is a function call or a pointer store.  The reason is that the
address of the variable was passed to an external function, and the
compiler does not (normally!) know what that function did with it.  It
may have assigned it to a global variable, causing *every* function to
have a potential alias to the "local" variable which had its address
taken. In that case, any function call has the possibility of modifying
the local variable, so it must be re-read from memory.  This is the type
of thing that the proposed "noalias" keyword for ANSI C was trying to
address (no pun intended ;-)

"Universal" optimizing compilers that perform inter-procedural
assignment-tracking may be able to determine that the variable is not
aliased, and therefore is free to be cached.


	-- Tim Olson
	Advanced Micro Devices
	(tim at crackle.amd.com)



More information about the Comp.lang.c mailing list