On Nov 23, 2007 9:45 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > So, yes, debug stmts and insns are notes in the sense that they don't > output code. Like USE insns, labels, empty asm insns and other > UNSPECs. But wait, those are insns, not notes. And they do generate > code, just not in the .text section, but rather in .debug sections.
All of them relate to code generation though. Without them, we create wrong code. I'm aware of how you feel about debug info and correctness and so on. > So, what's this prejudice against debug insns? Why do you regard them > as notes rather than insns? What worries me is that GCC will have to special-case DEBUG_INSN everywhere where it looks at INSNs. One can already see some of that happening on your branch. Apparently, you can't treat DEBUG_INSN just like any other normal insn. What I see happening with your DEBUG_INSN approach, is that all passes that use NEXT_INSN/PREV_INSN will have to special-case DEBUG_INSN in addition to the NOTE_P or INSN_P checks that they already have. I have seen too many bugs with passes who forgot to look through notes to feel comfortable about adding another not-a-note-but-also-not-an-insn like thing to the insn stream. The fact that DEBUG_INSN also has real operands that are not really real operands is bound to confuse the matter even more. Life with proper insn and operands iterators for RTL would be so much easier, but for the moment I fear you're just going to see a lot of duplication of ugly conditionals and bugs where such conditionals are forgotten/overlooked/missing. So to summarize: I'm just worried your approach is going to make GCC even slower, buggier, more difficult to maintain and more difficult to understand and modify. And the benefit, well, let's just say I'm not convinced that less elaborate efforts are not sufficient. (And to be perfectly honest, I think GCC has bigger issues to solve than getting perfect debug info -- such as getting compile times of a linux kernel down ;-)) Gr. Steven
