Re: Designs for better debug info in GCC

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

Alexandre Oliva <aoliva@redhat.com> writes:

> So...  The compiler is outputting code that tells other tools where to
> look for certain variables at run time, but it's putting incorrect
> information there.  How can you possibly argue that this is not a code
> correctness issue?

I don't see any point to going around this point again, so I'll just
note that I disagree.


> >> >> > 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.
> >> 
> >> It's not, really.  A reference to an object within a debug stmt or
> >> insn is very much like any other operand, in that most optimizer
> >> passes must keep them up to date.  If you argue for pushing them
> >> outside the IL, why would any other operands be different?
> 
> > I think you misread me.  I didn't argue for pushing debugging
> > information outside the IL.  I argued against a specific
> > implementation--DEBUG_INSN--based on our experience with similar
> > implementations.
> 
> Do you remember any other notes that contained actual rtx expressions
> and expected optimization passes to keep them accurate?

No.

> Do you think
> we'd gain anything by moving them to a separate, out-of-line
> representation?

I don't know.  I don't see such a proposal on the table, and I don't
have one myself, so I don't know how to evaluate it.

Ian