Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!cca!decvax!harpo!floyd!vax135!ukc!edcaad!edee!edai!ok
From: ok@edai.UUCP
Newsgroups: net.unix-wizards,net.lang.c
Subject: Some questions about the C -Optimiser
Message-ID: <2083@edai.UUCP>
Date: Thu, 2-Jun-83 16:58:26 EDT
Article-I.D.: edai.2083
Posted: Thu Jun  2 16:58:26 1983
Date-Received: Mon, 6-Jun-83 21:47:30 EDT
Lines: 63

/*  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.
*/