Re: Debug optimized code

Walter Banks <>
Thu, 25 Sep 2008 14:29:15 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: Debug optimized code (Stephen Horne) (2008-09-18)
Re: Debug optimized code (Barry Kelly) (2008-09-19)
Re: Debug optimized code (George Neuner) (2008-09-20)
Re: Debug optimized code (Hans-Peter Diettrich) (2008-09-21)
Re: Debug optimized code (Stephen Horne) (2008-09-22)
Re: Debug optimized code (George Neuner) (2008-09-23)
Re: Debug optimized code (Walter Banks) (2008-09-25)
Re: Debug optimized code (kamal) (2008-10-01)
Re: Debug optimized code (2008-10-04)
| List of all articles for this month |

From: Walter Banks <>
Newsgroups: comp.compilers
Date: Thu, 25 Sep 2008 14:29:15 -0400
Organization: Compilers Central
References: 08-09-076 08-09-105 08-09-110 08-09-115
Keywords: optimize, debug
Posted-Date: 26 Sep 2008 07:47:24 EDT

George Neuner wrote:

> My point is that a developer should never test/debug code compiled
> with one set of optimizations and then ship untested/undebugged code
> compiled using a different set of optimizations. "It works, now
> compile it for speed and ship it." I have seen people do this and
> it always backfires.

Essentially all of our customers are developing embedded applications.
A long time ago we decided to limit the code generation choices in or
compilers and concentrate on generating good tight code.

For 8 bit processors compiling for size generally produced fast code
with a few exceptions that compilers dealt with by context.

Some of the compilers were optimized to deal with intended
applications and others were implemented with an understanding of the
application and the development teams that would use the tools.

This opens questions on choices that compilers often make but are
controlled through optimization switches. A simple example of this is
loop unrolling. We searched literally tons of user code and although
we saw places that loops could be unrolled for performance or created
for size we also saw that the coding choice almost always was made by
a developer for some implementation purpose. We felt that this
conscience implementation choice on a case by case basis was important
to be left in the developer domain.

I had generally believed that optimization choices added to user
confusion in many cases and defocused compiler testing.

A few days before Stephan Ceram posted his question here and in 1 or 2
other newsgroups I ran across a developer using some one else's tools
set. George describes what was happening to this developer "It works,
now compile it for speed and ship it."

In the last couple weeks I have been seeing many developers who are
using tools where the source level debug information did not reflect
the choices the compiler made in code generation.


Walter Banks
Byte Craft Limited
Tel. (519) 888-6911

Post a followup to this message

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