Some questions about the C -Optimiser
ok at edai.UUCP
ok at edai.UUCP
Fri Jun 3 06:58:26 AEST 1983
/* Some questions about "optimised" C code.
*/
struct {unsigned a:24; unsigned b:8} x;
main()
{
int s, t; /*
*/ t = x.a; /* 1.
opt&un extzv $0,$24,_x,-8(fp)
*/ x.a = t; /* 2.
opt&un insv -8(fp),$0,$24,_x
*/ t = x.b; /* 3.
un extzv $24,$8,_x,-8(fp)
opt movzbl 3+_x,-8(fp)
*/ x.b = t; /* 4.
opt&un insv -8(fp),$24,$8,_x
why not movb -8(fp),_x+3 ??
*/ t = s&0xffffff; /* 5.
un bicl3 $-16777216,-4(fp),r0
un movl r0,-8(fp)
opt extzv $0,$24,-4(fp),-8(fp)
why not bicl3 $-16777216,-4(fp),-8(fp) ??
*/ t = s>>24; /* 6.
opt&un ashl $-24,-4(fp),r0
opt&un movl r0,-8(fp)
why not ashl $-24,-4(fp),-8(fp) ??
*/ } /*
The questions are
1: The use of byte addressing in (3) is a significant improvement,
about 3 micro-seconds as compared with 5 on a VAX 750. Why is
is not used in (4)?
2: bicl3 $(-1<<N),<source>,<dest> is a significant improvement over
extzv $0,$N,<source>,<dest> in speed (4 usec vs 5). Why is it not
used in (5)?
3: The C compiler has a very strong tendency to generate
<calculate answer in>,r0
movl r0,<dest>
even when <dest> doesn't appear in the calculation. How come the
peep-hole -Optimiser misses the opportunity of eliminating the
movl?
4: This is just a guess, because I don't know how -O works, but the
improvements referred to in q1 and q2 involve replacing one
instruction by one instruction, so should be fairly easy to add
to the -Optimiser. How may it be done? q3's cure is probably
very much harder. If these changes aren't improvements on the
11/780, perhaps there could be a #define for selecting the machine?
This isn't a frivolous problem constructed to "beat the optimiser".
We have a program which does these operations an awful lot, and a 10-20%
speedup obtained by making a few minor (and universally beneficial on
750s) tweaks to the compiler seems like a good bargain.
*/
More information about the Comp.unix.wizards
mailing list