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