Designs for better debug info in GCC

[Alexandre Oliva]

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

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

Not quite.  It's an insn.  But it is different in some ways.  It's not
unheard of.  Asm insns are also different in some ways.  USEs and
CLOBBERs too.  Delayed-branch instruction groups too.

It would be great if infrastructure for weak uses was already in
place, but if it's needed (we haven't determined that, but I'm
convinced there's no better way) and it isn't there, then it has to be
put in.

> And it has to handle this new case everywhere.

I've already explained why this isn't true.  It's not even close to
being true.  In fact, I've chosen this representation *precisely*
because I reasoned it would lead to the least global impact.  Of
course you can refuse to believe that and point at the changes I had
to make as alleged counter-proof, failing to notice how many other
locations I haven't had to change and that just work because adjusting
other instructions after transformations is precisely what all
transformation passes already do.

> I didn't say "complex conditionals" but ugly conditionals ;-)
> I mean all the "INSN_P && ! DEBUG_INSN_P" conditionals.

Oh, that's easy: NON_DEBUG_INSN_P can simplify that.  There are, what,
a few dozens of such tests in the compiler right now, compared with
the hundreds of tests for INSN_P and a few tens of tests for
DEBUG_INSN_P.  I didn't think it was worth creating yet another macro,
but if you find this so unacceptable, maybe I can rework it.

Would you prefer NON_DEBUG_INSN_P, or would you prefer the original
INSN_P and all uses thereof to be spelled differently, just to keep
the few objectionable INSN_P && ! DEBUG_INSN_P tests more beautiful?

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

Getting even the trivial cases wrong and dismissing those without
realizing how things would fall apart in the big picture looks like
"generating more incorrect information just for the sake of it" to me.
Now, maybe it's not.  Maybe it's just human behavior, a wish that some
simpler solution will take care of a problem and that the simple
counter-examples I've pointed out are rare situations.  I don't see
that they are.  I've put a lot of thought into this problem, I've been
working on it for quite a long time, and I've fallen in many of the
traps that I pointed out, and avoided several others.

I realize I come off as arrogant when I feel cornered by a majority
that obviously hasn't spent enough on the issue to realize the
obvious-to-me major problems with the alternatives that are on the
table.  I realize in such situations I often react in ways that are
detrimental to the points I'm trying to make.  I realize this doesn't
help.  I hope people can see through the mess of proposal-name-calling
that this is turning into.

> The "for the sake of it" part is just offensive.

I agree, and I apologize for that.  It's been a very frustrating
debate.

> You seem imply that people are arguing gcc should emit wrong debug
> information on purpose.

That's how it feels to me when the claims come up that it's not a
matter of correctness, or that it's not important to get it right.

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

I'm very happy you agree with him.  Unfortunately, you appear to be
focusing on the sloppiness afforded by the wording "good enough", and
assuming that this can be pushed beyond the point of "extract
*reliable* information", which is the key operative qualifier here.

If it's "good enough" for other purposes, but it's not possible to
"extract reliable information from debugging info", then we don't
satisfy the predicate above.

That's why I'm aiming at correctness (it's reliable) rather than
completeness (optimizations can discard stuff).

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

I happen to agree, indeed, but it's a correctness issue of the
implementation, not a correctness issue of the compiler output, which
is what I'm talking about when I speak of correctness issues.

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

I could, and that's a very good idea (thanks!), but it will be easier
to do that after my next merge, when there won't be fixes for missed
optimizations, that I detected with my testing, missing from the
baseline.

After all such missed optimizations are in the trunk, I intend to
merge that into the branch and compare mergepoint and branch for
compiler output changes other than in debug information.  If there are
any changes (extremenly unlikely), these are bugs that I'll have to
fix.

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