Can ANSI Standard C be "Optimized"

Bill Stewart HO 4K-437 x0705 wcs at homxa.UUCP
Thu Mar 15 05:43:45 AEST 1984


Martin Minow reports that:
	If I read the Draft ANSI Standard correctly, it would seem to preclude
	any optimizations across statement (;) boundaries.  
	..........
	Therefore, many of the failings of the C optimizers are inherent
	in the definition of the language, and not simply due to laziness
	on the part of the compiler writers.  (And, no, I don't know
	why this restriction was put in the draft standard.)

One reason optimization is difficult in C is the *EXISTENCE* of
pointers, which makes common-subexpression elimination very tough.
Consider the following code

	foo = bar * ( zed + bazoo / gletch)
	*ptr= foo
	baz = diddle( zed + bazoo / gletch )

The obvious optimization for the compiler to do is to calculate the
expression ( zed + bazoo / gletch ) once, store it in a temporary
location, and reuse it in the call to diddle.  However, the
assignment *ptr = foo could have changed the value of zed, bazoo, or
gletch, rendering the stored value useless.  For complicated expressions,
it may still be profitable to test "ptr==&zed || ptr==&bazoo ||
ptr==&gletch", instead of recalculating, but the utility is greatly
reduced.

In general, anything that has side-effects makes optimization
dangerous; assigning a value to *ptr may change the value of any
variable that ptr could point to.  This may be why the standard
limits optimization to very narrow locations, and is one reason why
overprotective languages like ADA(tm) or Modula-2 have their devotees.

				Bill
-- 
"The first major program written in ADA will be a COBOL interpreter."
					Stewart, 1984
Bill Stewart
AT&T Bell Labs, Holmdel NJ
HO 4K-437 x0705   (201-949-0705)
ho95b!wcs
ucbvax!ihnp4!ho95b!wcs
decvax1harpo!ho95b!wcs



More information about the Comp.lang.c mailing list