|[5 earlier articles]|
|Re: Debug optimized code email@example.com (Stephen Horne) (2008-09-18)|
|Re: Debug optimized code firstname.lastname@example.org (Barry Kelly) (2008-09-19)|
|Re: Debug optimized code email@example.com (George Neuner) (2008-09-20)|
|Re: Debug optimized code DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-09-21)|
|Re: Debug optimized code firstname.lastname@example.org (Stephen Horne) (2008-09-22)|
|Re: Debug optimized code email@example.com (George Neuner) (2008-09-23)|
|Re: Debug optimized code firstname.lastname@example.org (Walter Banks) (2008-09-25)|
|Re: Debug optimized code email@example.com (kamal) (2008-10-01)|
|Re: Debug optimized code firstname.lastname@example.org (2008-10-04)|
|From:||Walter Banks <email@example.com>|
|Date:||Thu, 25 Sep 2008 14:29:15 -0400|
|References:||08-09-076 08-09-105 08-09-110 08-09-115|
|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.
Byte Craft Limited
Tel. (519) 888-6911
Return to the
Search the comp.compilers archives again.