On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
