Re: DEBUG_INSN that is not an insn

2 msg	Wrong ChangeLog entry in gcc/ChangeLog
1 msg	gcc-4.1-20071105 is now available
2 msg	Question regarding GCC fdump option
2 msg	Documentation Error in Using the GNU Compiler C...

DEBUG_INSN that is not an insn
\ Steven Bosscher (5 Nov 2007)
. \ Richard Guenther (5 Nov 2007)
. \ Eric Botcazou (5 Nov 2007)
. \ Alexandre Oliva (7 Nov 2007)
. \ Alexandre Oliva (20 Dec 2007)
. . \ Steven Bosscher (20 Dec 2007)

16 msg	GCC 4.3.0 Status Report (2007-11-04)
1 msg	The Linux binutils 2.18.50.0.3 is released
27 msg	strict aliasing
2 msg	Why is this still not allowed by gcc while MSVC...
13 msg	GNAT is required to build ada
1 msg	gcc-4.3-20071102 is now available
16 msg	Tree-SSA and POST_INC address mode inompatible ...
2 msg	Dependency output
12 msg	Results of 7z-4.55 performance with current GCCs.
3 msg	Old UTF16 patch
2 msg	What means the fat .gch file?
2 msg	New FAILures on MIPS: g++.dg/tree-ssa/ivopts-1....
16 msg	undocumented optimization options
3 msg	Last argument of lang_hooks_for_callgraph.analz...
2 msg	Can CODE_FOR_$(div$V$I$a3$) ever match?

Subject:	Re: DEBUG_INSN that is not an insn
Group:	Gcc
From:	Alexandre Oliva
Date:	7 Nov 2007

On Nov 5, 2007, "Steven Bosscher" <stevenb.gcc> wrote:

> I am worried about some of the things going on in the
> var-tracking-assignments branch. The thing that worries me most, is
> the introduction of an insn that is not an instruction:

> /* An annotation for variable assignment tracking. */
> DEF_RTL_EXPR(DEBUG_INSN, "debug_insn", "iuuBieie", RTX_INSN)

> DEBUG_INSN is more like a note, AFAIU.

In some senses, yes. In others, no.

It is a note in the sense that we don't generate code for it.

It's an insn in the sense that optimization passes need to adjust
references in it as they modify the code elsewhere.

So it's more like a USE insn, except that it's a weak USE, in that
optimization passes shouldn't refrain from performing optimizations
just because of such weak USEs.

> I couldn't find any discussions about this idea, so I don't know if
> there is "sufficient" concensus that this is the right thing to do.

I don't think there's any consensus, indeed. What I have is a
proposal of WIP, but I'm quite convinced that there's no better
alternative. See http://gcc.gnu.org/ml/gcc/2007-11/msg00176.html for
the rationale on the design I've chosen.

> Also, registers mentioned in DEBUG_INSNs are counted as real uses,

Except when they aren't because I've modified the counting routines so
as to disregard them ;-)

> which is bound to confuse some existing RTL analyses, and makes it
> harder to implement new ones safely.

The alternative is to keep them out of band, which makes it even more
likely that they are forgotten and left out of date. And since we
don't have comprehensive debug info testing infrastructure, we have
silent failures. With the approach I've taken, there's still a
possibility of silent failures in debug info, but it's far less
likely, for the most common failure mode I've observed (with the
caveat that I don't have a debug info testsuite) has been that of
failure to perform optimizations because of the presence of debug
annotations.

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