This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
DEBUG_INSN that is not an insn
- From: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
- To: GCC <gcc at gcc dot gnu dot org>, "Alexandre Oliva" <aoliva at redhat dot com>
- Cc: "Kenneth Zadeck" <zadeck at naturalbridge dot com>, "Jan Hubicka" <hubicka at ucw dot cz>
- Date: Mon, 5 Nov 2007 10:29:22 +0100
- Subject: DEBUG_INSN that is not an insn
Hello,
While browsing through the mailing list archives a bit, I noticed
Alex's project to improve GCC's debug information. This seems like a
really interesting and worthwhile project. Alex, maybe you could add a
Wiki page about this project, in the style of
http://gcc.gnu.org/wiki/SampleProjectTemplate ... ?
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. 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.
IMHO, anything that is not an instruction should not be true under
INSN_P. Yet, INSN_P returns true for DEBUG_INSN. This is already
leading to a lot of special-casing of DEBUG_INSN throughout the RTL
bits of the compiler on the branch.
Also, registers mentioned in DEBUG_INSNs are counted as real uses,
which is bound to confuse some existing RTL analyses, and makes it
harder to implement new ones safely.
The same issues arise with DEBUG_STMT for tree-ssa.
Is this really a design that has the necessary support to make the
branch eligible for merging into the trunk? What are the reasons for
using a fake insn instead of a note for DEBUG_INSN?
Thanks,
Gr.
Steven