🚀 go-pugleaf

Gcc generates less efficient code for the `++E' construct than it does
for the equivalent `E+=1', a suprising result given that the pre- and
post-increment forms are intended to make it easier for compilers to
find the most efficient code.  Below are some sample 88k assembly
fragments illustrating the effect.  The inefficiency (I hesitate to
call it a problem) seems to originate in the way expand_increment()
converts a preincrement tree to rtl (done in a funny way in order to
get around a nasty protect_from_queue() side effect in expand_binop()),
and hence is likely to affect more than just the 88k.

Compiler options: -O.  Compilers tested: 2.2.2, 2.3.1, 2.3.3.  System:
m88k-realix (a svr3 motorola delta box derivative; for C, equivalent to
m88k-motorola).

We noticed this only because it came up in some critical sections of
our code; for now, we have converted the most affected statements to the
equivalent assignment form.

; f(sp)
; register short *sp;
; {
;  return ++(*sp);
; }
_f:
	ld.hu	 r9,r0,r2
	addu	 r9,r9,1
	st.h	 r9,r0,r2
	ld.h	 r2,r0,r2  ; why the extra load?  should be an ext r2,r9,16<0>
	jmp	 r1


; g(sp)
; register short *sp;
; {
;   return (*sp)+=1;
; }
_g:
	or	 r9,r0,r2
	ld.hu	 r2,r0,r9
	addu	 r2,r2,1
	st.h	 r2,r0,r9
	jmp.n	 r1
	ext	 r2,r2,16<0>

Any changes to gcc will also have to pass the following stress test.
This causes emit_queue() to be called at the appropriately nasty point,
and will result in subtly defective assembly code if the fix is invalid
(naturally, I have not been able to find an efficient, valid fix to
expand_increment() that passes this test).

f(sp)
short *sp;
{
  return (++(*sp)) >= 0 ? g(sp) : 0;
}

-- 
Joe Korty,  REAL/IX Operating Systems

MODCOMP, an AEG Company			Telephone: (305) 977-1820
1650 West McNab Road			Fax:	   (305) 977-1638
P.O. Box 6099				E-mail:	   uunet!modcomp!joe
Ft. Lauderdale, FL 33309-1088