TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"W. Wesley Groleau (Wes)" <[log in to unmask]>
Thu, 9 Jan 1997 13:09:12 EST
<01IE0BM4VQYU90NZPK@YGVX04>; from "Pickett, Michael" at Jan 9, 97 12:05 (noon)
"W. Wesley Groleau (Wes)" <[log in to unmask]>
text/plain (51 lines)
:> > I always figured it to turn off the optimizer for one out of a hundred
:> > files was a lot easier than some of the code contortions people would
:> > write for the sake of "hand-optimizing".
:> I find this difficult to understand. If you understand in detail all the bugs
:> in your compilation system and you have tools to inspect your source code so
:> that you can identify any files that might suffer from the bugs, then perhaps
:> I /would/ agree. My experience is different. Compiler bugs tend to be
:> pathelogical, otherwise they would have been found before and fixed (I'm an
:> optimist). Often they cause the code to behave oddly under obscure situations
:> which, sadly, don't always get tested. If an optimiser significantly
:> increases the incidence of latent bugs, that is bad news.

But when it's less than one percent, AND you have adequate testing,
my "personal" process was that when I traced a bug to a particular unit,
I would try it with that unit "unoptimized".  If the bug went away,
announce "fixed".

:> Our systems here are built from many hundreds of files. Productivity
:> requirements lead us to adopt an approach to the building of these systems
:> which is sytematic and largely mechanised. Special cases, such as supressing
:> the optimiser, are not welcome, and hence my comment earlier about the need
:> for tool support.

Our system was about five million Ada statements.  In order to speed up
compilation, we (not I personally) wrote "wrapper" tools to call the compiler.
The wrapper would farm out the compilations to different hosts in parallel.
Since that meant that the wrapper was called for EACH file, it would have
been no problem for the wrapper to check some Configuration Management
file for the correct optimization level.  In our case, even that would not
be necessary, since the compiler itself created/updated/used an "options"
file which told it the optimization level to use for each file.

We even had one and only one source file that would crash the compiler if
we used an optimization level other than ONE. (Zero was no optimization,
one was minimal, two through nine provided greater optimization.)

I should also clear up something else:  I said that the Verdix optimizer
had bugs which affected less than one percent of source files.  I should
have also mentioned that most of the bugs aborted the compilation; only a
few actually generated bad code.

We are straying off the charter of this list, though, so if you wish to
continue discussing it, I'd suggest direct email.

W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-41)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): [log in to unmask]