Orphaned Response

Ozan Yigit oz at yetti.UUCP
Fri Jul 5 12:28:48 AEST 1985


In article <504600001 at hpdcdb.UUCP> mike at hpdcdb.UUCP (mike) writes:
>The chief reason pcc compilers cannot make intelligent register variable
>selection automatically is that they are single-pass compilers. Some kind
>of usage count is necessary to select candidates for register variables.
>By the time the compiler can accumulate a usage count, however, a
>single-pass compiler has already generated code.

	VMS C compiler is essentially a single pass compiler also,
	(It performs the second pass if the program contains any case
	statements) yet, it is a well known REGISTER HOG !!! It will
	use every register, including AP, when it is available.. 
>
>usage counts. Consequently I've yet to see a compiler algorithm for
>automatic register variable selection that can beat explicit programmer
>selection. If anyone does have such an algorithm, please share it.
>
	Check out the DEC book on their PL/1 and C compilers. (I cannot
	remember the full title..)
>
>Given the gutsy nature of C that allows the programmer great freedom
>to allocate registers as he sees fit, I would not be surprised at all
>if an automatic register allocator was greeted with loud cries of anguish
>from the programmer community.
>
	I think the opinion is divided on that. Especially on RISC
	architectures, programmer could stifle the compiler from
	generating better code by not properly declaring the
	variables (assuming that the compiler is good old pcc,
	and does not use registers unless told). 
	On the other hand, compiler should definately accept "advise" 
	from the programmer, since henry at utzoo is so fond of reminding, 
	compilers (and program beautifiers..) cannot read minds. 
	Cornell tried to read minds at one time with their PL/C 
	compiler. It did not work too well.

>Register variables do alter the behavior of certain programs because
>the pcc compiler generates code sequences based on cost estimates. Since
>the use of register variables reduces the cost of certain subtrees it
>can change the order of evaluation in the generated code. 

	Is this an argument *for* or *against* the register variables ??
	There is no question that certain optimization techniques may
	alter the order of evaluation by means of loop unrolling[1], or
	code motion out of loops[1], but under *no* circumstances
	should this provide a different result. Otherwise, compiler
	should be considered *broken*. 

>Mike McNelly

	[1] Bentley, Jon Luis, "Writing Efficient Programs",
	    Prentice-Hall, 1982
-- 

Oz	[all wizardesque side effects are totaly unintentional,
	unless stated otherwise..]

	Usenet: [decvax | allegra | linus | ihnp4] !utzoo!yetti!oz
	Bitnet: oz@ [yuleo | yuyetti]
-------------
Support GNU. Consider the 3-muskateers' motto:
	ONE FOR ALL - ALL FOR ONE



More information about the Comp.lang.c mailing list