Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva@redhat.com>]

On Nov 23, 2007, "Steven Bosscher" <stevenb.gcc@gmail.com> wrote:

>> So, what's this prejudice against debug insns?  Why do you regard them
>> as notes rather than insns?

> What worries me is that GCC will have to special-case DEBUG_INSN
> everywhere where it looks at INSNs.

This is just not true.  Anywhere that simply wants to update insns for
the effects of other transformations won't have to do that.  Only
places in which we need the weak-use semantics of debug_insns need to
give them special treatment.  Not because they're not insns, but
because they're weak uses, i.e., uses that shouldn't interfere with
optimizations.

Yes, catching all such cases hasn't been trivial.  If we miss some,
then what happens is that -O2 -g -fvar-tracking-assignments outputs
different executable code than -O2.  Everything still works just fine,
we eventually get a bug report, we fix it and move on.

This is *much* better than starting out with notes, that nearly
nothing cares about, and try to add code to update the notes as code
transformations are performed.  In this case, we get incorrect,
non-functional compiler output unless we catch absolutely all bugs
upfront.

> Apparently, you can't treat DEBUG_INSN just like any other normal
> insn.

Obviously not.  They're weaker uses than anything else.  We haven't
had any such thing in the compiler before.

> but for the moment I fear you're just going to see a lot of
> duplication of ugly conditionals

Your fear is understandable but not justified.  Go look at the
patches.  x86_64-linux-gnu now bootstraps and produces exactly the
same code with and without -fvar-tracking-assignments.  And no complex
conditionals were needed.  The most I've needed so far was to ignore
debug insns at certain spots.

It's true that in a number of situations this is an oversimplified
course of action, and some additional effort might be needed to
actually update the debug insns when they would have interfered with
optimizations.  Time will tell, I guess.  So far, it doesn't look like
it's been a problem, and I don't foresee these duplicated or ugly
conditionals you fear.

> and bugs where such conditionals are forgotten/overlooked/missing.

See above.  One of the reasons for the approach I've taken is that
such cases will, in the worst case, cause missed optimizations, not
incorrect compiler output.

> And the benefit, well, let's just say I'm not convinced that less
> elaborate efforts are not sufficient.

Sufficient for what?  Efforts towards what?  Generating more incorrect
debug information just for the sake of it?  Adding more debug
information while breaking some that's just fine now?  Is that really
progress?

> (And to be perfectly honest, I think GCC has bigger issues to solve
> than getting perfect debug info -- such as getting compile times of a
> linux kernel down ;-))

Compile speed is a quality of implementation issue.  Output
correctness and standard compliance comes first in my book.

And then, I'm supposed to fix this correctness problem, not other
issues that others might find more important.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}