[gnu.gcc.bug] GCC 1.35 optimizer inefficiencies

apratt@AMES.ARC.NASA.GOV (Allan Pratt) (06/16/89)

I wish to point out two inefficiencies in the code generator/optimizer
for GCC version 1.35 on the 68000 (not 68020).

First, the compiler should be informed that "clrl d0" takes 150% as 
long as "moveql #0,d0" on a 68000.  Alternatively, the assembler could
make the optimization, if you don't mind having an optimizing
assembler. (The time difference is 6 clocks for clr vs 4 for moveq.)

Second, with -O the compiler took this:

long foo;
long bar;

main()
{
	int i;
	i = foo + bar;
	return i;
}

and produced this:

#NO_APP
gcc_compiled.:
.text
	.even
.globl _main
_main:
	link a6,#0
	movel _foo,d0
	addl _bar,d0
	unlk a6
	rts
.comm _bar,4
.comm _foo,4

That's fine, but if both foo and bar are declared "volatile," the
output is this:

#NO_APP
gcc_compiled.:
.text
	.even
.globl _main
_main:
	link a6,#0
	movel _foo,d0
	movel _bar,d1
	addl d1,d0
	unlk a6
	rts
.comm _bar,4
.comm _foo,4

Now, just because something is volatile, it shouldn't be totally
brain-damaged about combining "movel _bar,d1" and "addl d1,d0" into the
single instruction "addl _bar,d1" should it?

If only foo is volatile, you get "movel _foo,d0 / addl _bar,d0"  (the
same goes for having only bar volatile).  This is just an example,
of course.  If you use a lot of volatiles, this can really add up.

Neither -fcombine-regs nor -fforce-mem, nor both, helped.

Thanks for letting me tell you about this.  Is GCC 1.35 out of date? 
After all, it's possible that you've already improved the code
generation...

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt