Re: Designs for better debug info in GCC

[Ian Lance Taylor <iant at google dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> > Your approach gives you a point solution--did anything change
> > today--but it doesn't give us a maintenance solution--did anything
> > change over time?
> 
> Actually, no, your assessment is incorrect.

Ah, you're right.  I was wrong.


> > While I understand that you were given certain requirements, for the
> > purposes of mainline gcc we need to weigh costs and benefits.  How
> > many of our users are looking for precise debugging of optimized code,
> > and how much are they willing to pay for that?  Will our users overall
> > be better served by the 90% solution?
> 
> Does it really matter?  Do we compromise standards compliance (and so
> violently, while at that) in any aspect of the compiler?

What standards are you talking about?  I'm not aware of any standard
for debuggability of optimized code.

At one time, gcc actually provided better debugging of optimized code
than any other compiler, though I don't know if that is still true.
Optimized gcc code is still debuggable today.  I do it all the time.
(For me poor support for debugging C++ is a much bigger issue, though
I think that is an issue more with gdb than with gcc.)

gcc's users are definitely calling for a faster compiler.  Are they
calling for better debuggability of optimized code?


> >> 1. every single gimple assignment grows by one word,
> 
> I take this back, I'd been misled by richi's description.  It's really
> a side hashtable (which gets me worried about the re-emitted rather
> than modified gimple assignments in some locations), so it doesn't
> waste memory for gimple assignments that don't refer to user
> variables.
> 
> Unfortunately, this is not the case for rtx SETs, in this alternate
> approach.

Obviously the memory requirements of both approaches will need to be
measured.


> > We've fixed many many bugs and misoptimizations over the years due to
> > NOTEs.  I'm concerned that adding DEBUG_INSN in RTL repeats a mistake
> > we've made in the past.
> 
> That's a valid concern.  However, per this reasoning, we might as well
> push every operand in our IL to separate representations, because
> there have been so many bugs and misoptimizations over the years,
> especially when the representation didn't make transformations
> trivially correct.

Please don't use strawman arguments.


As I understand your proposal, it materializes variables which were
otherwise omitted from the generated program.  It doesn't address the
other issues with debugging optimized code, like bouncing around
between program lines.  Is that correct?  What else does your proposal
do?

Ian