Re: Designs for better debug info in GCC

["Steven Bosscher" <stevenb.gcc@gmail.com>]

On Nov 23, 2007 9:45 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> So, yes, debug stmts and insns are notes in the sense that they don't
> output code.  Like USE insns, labels, empty asm insns and other
> UNSPECs.  But wait, those are insns, not notes.  And they do generate
> code, just not in the .text section, but rather in .debug sections.

All of them relate to code generation though.  Without them, we create
wrong code.  I'm aware of how you feel about debug info and
correctness and so on.

> 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.  One can already see some of that
happening on your branch.  Apparently, you can't treat DEBUG_INSN just
like any other normal insn.

What I see happening with your DEBUG_INSN approach, is that all passes
that use NEXT_INSN/PREV_INSN will have to special-case DEBUG_INSN in
addition to the NOTE_P or INSN_P checks that they already have.  I
have seen too many bugs with passes who forgot to look through notes
to feel comfortable about adding another
not-a-note-but-also-not-an-insn like thing to the insn stream. The
fact that DEBUG_INSN also has real operands that are not really real
operands is bound to confuse the matter even more.  Life with proper
insn and operands iterators for RTL would be so much easier, but for
the moment I fear you're just going to see a lot of duplication of
ugly conditionals and bugs where such conditionals are
forgotten/overlooked/missing.

So to summarize: I'm just worried your approach is going to make GCC
even slower, buggier, more difficult to maintain and more difficult to
understand and modify.  And the benefit, well, let's just say I'm not
convinced that less elaborate efforts are not sufficient.

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

Gr.
Steven