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