Re: Designs for better debug info in GCC

[Robert Dewar <dewar@adacore.com>]

My general feelings on this subject:

1. I don't think we should care much about the ability to
*SET* values of variables in optimized code. You can
definitely do without that. So if a variable exists in
two places, no problem, just register one of them.

2. It is much more important to have reasonable debugging
for most users than the last mile of optimization. For me
we should ensure that -O1 is still reasonably debuggable.
The switch to GCC 4, at least in the Ada context, has
significantly degraded -O1 debugging. I have found for
instance that debugging the GNAT compiler itself, -O1
used to be perfectly fine, but now far too many arguments
and variables disappear.

3. The quality of code at -O0 is really terrible compared
to the competition (at least in the case of Ada), and
large scale programs are just too big at -O0 to be
practical (there is a big difference between a 50
megabyte image and a 100 megabyte image). So we really
cannot rely on using -O0 for debugging. At -O1 we are
more than competitive for performance with competing
compilers.

4. In any case, most users really prefer to test and
debug at the same optimization level that they will
use for delivery. As noted above, -O0 is seldom practical
for delivery (furthermore the voluminous extra code makes
certification at the object level more work). -O1 is a
fine compromise from a performance point of view, but
needs to be debuggable.

5. Among our users we have relatively few who care about
even a factor of 2 in performance, and VERY few who care
about 10%. On the other hand we have lots of customers
who definitely have severe problems with the lack of
debuggability of -O1 code.

5. We have talked sometime about a -Od level or somesuch
that would be fully debuggable. That's an interesting
idea, but I think in practice it is more reasonable to
try to ensure good debugging at -O1. Optimizations that
significantly intefere with debugging should be moved
to -O2. I think it is fine for -O2 to mean "optimize
the heck out of the program, I really care about the
last ounce of optimization, and I know debuggability
will suffer."