C "optimization"

[J. Shapiro]

Some of you may find this one interesting:

Given the following (fairly trivial) C program:

main()
{
        int a=5, b=4, c=3, d=2, e=1;

        a = b + c;
        e = c + d + b;
}

unoptimized ULTRIX cc and 4.2 BSD gives assembly code which amounts to

	push the constants onto the stack
	add b + c, move result to a
	add c + d, put it in R0
	add e to R0, move result to e
	set up return value
	exit

optimizing causes it to use registers a bit more.

unoptimized VMS cc generates essentially the same code as optimized ULTRIX cc,
though it pushes the constants onto the stack in the opposite order.

Here is the kicker:

Optimized VMS cc generates code which amounts to

	set up return value
	exit

having concluded that all variables in the system are dead at all points.
Inserting a printf of the values a and e after the assignments results in
(Hang on to your seats):

	push 9
	push 7
	call printf
	set up return value
	exit

I am afraid I got off into a tangent relating to finding common
subexpressions, and decided to try the above compilation hoping that
some version of the compilation would spot the obvious optimization of
changing the second line to read, in effect:

	e = a + d

In the process of finding out that no one seems to do this, I have lost
some respect for the UNIX "optimizer".  Now, can anyone mail me a
coherent reasoning for why UNIX cc is so inexcuseably stupid (at the
moment our postings are going out, but our incoming feed is dead)?
Can someone redeem my respect for the optimizer?

Jon Shapiro
Haverford College
-- 
Jonathan S. Shapiro
Haverford College

	"It doesn't compile pseudo code... What do you expect for fifty
		dollars?" - M. Tiemann