|Where would you like to spend that resource? (WAS: yup!) email@example.com (1991-08-19)|
|Re: Where would you like to spend that resource? (WAS: yup!) firstname.lastname@example.org.Virginia.EDU (1991-08-21)|
|Re: Where would you like to spend that resource? (WAS: yup!) email@example.com (1991-08-22)|
|Re: Where would you like to spend that resource? (WAS: yup!) firstname.lastname@example.org (1991-08-22)|
|Re: Where would you like to spend that resource? (WAS: yup!) email@example.com (1991-08-31)|
|From:||firstname.lastname@example.org (Michael Meissner)|
|In-Reply-To:||email@example.com's message of 22 Aug 91 13:20:07 GMT|
|Date:||Sat, 31 Aug 91 16:32:51 -0400|
Eliot Moss writes:
| 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.
In two of the GCC ports I have worked on (m88k, and mips), I have come
across situations where the optimized code is fine, and it only fails
if optimizing is turned off. This is because the combiner in GCC will
change the code to not use the bad patterns, and that I typically
spend more time testing optimized code vs. unoptimized code.
Also I should note, the first commericial compiler I worked on (DG/L
for Data General) had no options for optimization on or off. You
always ran the optimizer (which was a reasonable optimizer, including
doing code motion from nested functions to the outer functions).
Michael Meissner email: firstname.lastname@example.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Return to the
Search the comp.compilers archives again.