Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!genrad!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.unix-wizards,net.lang.c
Subject: Re:  Optimizing r0
Message-ID: <165@umcp-cs.UUCP>
Date: Tue, 14-Jun-83 21:53:11 EDT
Article-I.D.: umcp-cs.165
Posted: Tue Jun 14 21:53:11 1983
Date-Received: Wed, 15-Jun-83 20:06:38 EDT
Lines: 46


	From: bj@yale-com.UUCP

	    Suggestion:  change the optimizer to go ahead and
	    optimize if the r0 instructions are followed by anything
	    except a 'ret'.  The C compiler will only generate an
	    r0 instruction that also includes the return value
	    before a return(e), correct?

	This could cause problems in cases like
		return ( e ? a = b+1 : c = d+1 )

I just checked, and the compiler puts out (approximately)

	tstl	e
	jeql	L9998
	addl3	$1,b,r0
	movl	r0,a
	jbr	L9999
L9998:
	addl3	$1,d,r0
	movl	r0,c
L9999:
	ret

which follows my rule:  the r0 instruction comes immediately before
a return.  Maybe I should clarify "immediately".  I mean that
excluding branches, all statements before the ret must reference
r0.  If not, r0 is not the return value.  So the optimizer reads
the first addl3/movl pair; they are both r0 instructions.  The
jbr is followed (since it's an unconditional branch) to the ret,
thus r0 cannot be optimized.  The optimizer reads the second
addl3/movl pair; they are both r0 instructions.  The next thing
is a ret; no optimization.  But writing

	if (e)
		a = b + 1;
	else
		c = d + 1;
	;

will get optimized, since the  will (most likely) generate
non-r0 instructions.  At worst  will use r0 or be a
return, in which case you get no optimization; so it goes.

				- Chris