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