Re: Where would you like to spend that resource? (WAS: yup!)

There is one point that I think was missed in the previous posting. I agree
about use and non-use of optimization during development and about turning
run-time checks on and off. The point that I feel was missed is that since
optimization is complicated, it tends to harbor the most compiler bugs, which
can break program in very subtle and difficult to discover ways. This
certainly implies that very thorough testing needs to be done on the optimized
code (which I suspect many people do not do). It also suggests that there is a
real correctness vs. performance tradeoff introduced by our inability to prove
that production optimizing compilers are correct. I am not sure how big a
problem it is. I have been able to trace almost all cases of differences in
behavior between optimized and unoptimized code with most compilers to bugs in
the original program, but ones that testing might not reveal. For example, in
a recent instance a student of mine failed to include the keyword "return" in
some C code. The expression was calculated, and just happened to be left in
the result register, so the program worked unoptimized. The optimizer left the
result somewhere else and the program failed. This just backs up the necessity
of testing optimized code, too. Anyway, I hope this gives more food for
thought on the issue .... Eliot Moss
--


J. Eliot B. Moss, Assistant Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


--

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