On 11/5/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: > 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?
No, I don't think so. Also, see http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00200.html for a different approach (ok, that's not the current state). For RTL we chose to extend SET by a bitmap argument featuring the debug symbols affected by this set. Richard.
