This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]