Re: Debugging of optimized code

Charles Fiterman <cef@geodesic.com> wrote:
>The first question about debugging optimized code is "Why does the user
>want to do it?" The answer may be "Because the bug doesn't show up with
>the optimizer turned off."


It seems to me that this turns things around, since I would ask the question
"Why does the user want to turn off optimization?". The usual reasons are 1)
compilation speed, 2) the optimizer is buggy, 3) the optimized code isn't
debuggable. As processors and compilers become faster, compilation speed
becomes less of an issue. And optimizer bugs should be no different from
other compiler bugs and in fact tend to propagate where optimization is
considered an add-on. Ideally, one would like to have a single method for
compilation, rather two different methods, one for development and one for
production. Not being able to debug optimized code may mean a) inconvenience
for the developer b) duplication of build scripts or complications in
Makefiles c) dual versions of libraries, one optimized and one not d) an
otherwise unnecessary distinction between performance issues and other code
quality issues, possibly leading to ignoring performance altogether e)
difficulty in distinguishing between optimized and unoptimized objects
produced from the same sources, possibly leading to tracking problems and even
the erroneous distribution of unoptimized executables.


>This means various forms of turning off optimization or hideing its
>effects are useless or worse.


Indeed. We should move toward optimization as the norm. The notion of
turning on optimization only to produce a "production" version should become
obsolete.
--
<J Q B>
--

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