Unsafe optimzations

mo@bellcore.com (Michael O'Dell)
Sat, 17 Aug 91 15:21:52 GMT

          From comp.compilers

Related articles
Re: Writing fast compilers... glew@pdx007.intel.com (1991-08-16)
Unsafe optimzations mo@bellcore.com (1991-08-17)
Re: Unsafe optimzations mash@mips.com (1991-08-19)
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: mo@bellcore.com (Michael O'Dell)
Keywords: optimize, Fortran, design
Organization: Center for Chaotic Repeatabilty
References: <1991Aug15.205912.6553@sono.uucp> 91-08-072
Date: Sat, 17 Aug 91 15:21:52 GMT

Long ago, Fortran compilers capable of very aggressive optimizations came
with a knob for adjusting the level of aggression, and a manual which
described exactly the kinds of things that could get you into trouble. CDC
FTN called them "unsafe optimizations" (which came in two levels of
unsafety), IBM Fortran H used some other term, but the bottom line was the
same. These optimizations were well worth the trouble to use for some
programs but not all, and if you wanted to use them, then it was the
responsibility of the programmer to insure that the necessary conditions for
correctness were indeed met. Now I know that everyone has his own pet horror
story of something cute done by one of these compilers to some unsuspecting
boob who cranked up the optimizer to Full Tilt, and the compiler promptly
optimized away the executability of the program. But the fact remains that
this approach is exceptionally valuable.

In the example case of multi-hop pointer chasing in C, there is no way in the
world for any compiler to divine whether that is safe to eliminate such
chains ("volatile" declarations being a cruel hoax at best). And if the
programmer can't help, then it either doesn't matter (ie, if the programmer
doesn't know any reason it's dangerous, it is probably safe), or the guy gets
what he deserves for writing a program he doesn't understand. (I'm thinking
here of places in device drivers where such things MUST be used for reasons
the programmer has no control over but which must be understood in
excrutiating detail.)

So, it doesn't break my heart that the random C compiler doesn't do Cosmic
Subexpression Elimination. Frankly, I wouldn't trust it if it thought it
could because I have as much faith in the compiler's dark corners as I do any
other piece of software's dark corners. Good compilers are no substitute for
good programmers, and any attempt to make them so is at best misguided.
HOWEVER, this is NOT to say that good compilers cannot materially assist any
programmer of any skill level. It's just that the best approach is
controllable intervention just in case the compiler's omniscience falters.

(yes, I know that most C compilers have knobs, too.)

-Mike O'Dell

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.