Re: Designs for better debug info in GCC

["Steven Bosscher" <stevenb dot gcc at gmail dot com>]

On Nov 24, 2007 5:54 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> > 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.

So we get a "third way".  GCC has insns and notes, and now it gets a
third object to deal with in the insns stream.  And it has to handle
this new case everywhere.  To me it seems that your approach will not
help to make GCC easier to work with and understand.  Unless there are
compelling reasons to do this, I think this is a step in the wrong
direction.


> > 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.

I didn't say "complex conditionals" but ugly conditionals ;-)
I mean all the "INSN_P && ! DEBUG_INSN_P" conditionals.  There seem to
be a lot of those, and it's not immediately obvious where and when
you'd need them.


> > 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.

Ah! More on that later.


> > 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?

Ah, there you go again with this extremist pro-debug-info stance.  How
can one argue with you when you keep ridiculing other points of view
using ridiculous arguments?  Who said anything about "generating more
incorrect information just for the sake of it"?  I don't think anyone
did.  The "for the sake of it" part is just offensive. You seem imply
that people are arguing gcc should emit wrong debug information on
purpose.  Please step out of your own world of thoughts for a second,
and try to understand that other people can have a different but
nevertheless reasonable point of view.

I think it is impossible to get perfect debug info after very complex
code transformations.  And because of that, I also think it is
reasonable to not get perfect debug info in less complex cases.  Your
colleague expressed perfectly how I define "sufficiently good debug
info":

"It needs to be good enough
that a semi-knowledgable person or a dumb but heuristic-laden program
that processes debugging info can nevertheless extract reliable
information."
(http://gcc.gnu.org/ml/gcc/2007-11/msg00581.html)

Note how this "good enough" does not imply correctness at all cost".


Here is another "extremist" point of view:

Correctness for a optimization algorithm means that it does not miss
optimization opportunities that it is designed to catch.  Therefore if
an optimization algorithm implementation misses an optimization that
it should catch, then this is a correctness issue.
;-)

You said you now get the same code with and without
-fvar-tracking-assignments on your branch.  Can you also prove that
the branch does not introduce new missed optimizations wrt. the latest
revision that you merged from the trunk?

Gr.
Steven