On Nov 23, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
>> 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. This is just not true. Anywhere that simply wants to update insns for the effects of other transformations won't have to do that. Only places in which we need the weak-use semantics of debug_insns need to give them special treatment. Not because they're not insns, but because they're weak uses, i.e., uses that shouldn't interfere with optimizations. Yes, catching all such cases hasn't been trivial. If we miss some, then what happens is that -O2 -g -fvar-tracking-assignments outputs different executable code than -O2. Everything still works just fine, we eventually get a bug report, we fix it and move on. This is *much* better than starting out with notes, that nearly nothing cares about, and try to add code to update the notes as code transformations are performed. In this case, we get incorrect, non-functional compiler output unless we catch absolutely all bugs upfront. > Apparently, you can't treat DEBUG_INSN just like any other normal > insn. Obviously not. They're weaker uses than anything else. We haven't had any such thing in the compiler before. > but for the moment I fear you're just going to see a lot of > duplication of ugly conditionals Your fear is understandable but not justified. Go look at the patches. x86_64-linux-gnu now bootstraps and produces exactly the same code with and without -fvar-tracking-assignments. And no complex conditionals were needed. The most I've needed so far was to ignore debug insns at certain spots. It's true that in a number of situations this is an oversimplified course of action, and some additional effort might be needed to actually update the debug insns when they would have interfered with optimizations. Time will tell, I guess. So far, it doesn't look like it's been a problem, and I don't foresee these duplicated or ugly conditionals you fear. > and bugs where such conditionals are forgotten/overlooked/missing. See above. One of the reasons for the approach I've taken is that such cases will, in the worst case, cause missed optimizations, not incorrect compiler output. > And the benefit, well, let's just say I'm not convinced that less > elaborate efforts are not sufficient. Sufficient for what? Efforts towards what? Generating more incorrect debug information just for the sake of it? Adding more debug information while breaking some that's just fine now? Is that really progress? > (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 ;-)) Compile speed is a quality of implementation issue. Output correctness and standard compliance comes first in my book. And then, I'm supposed to fix this correctness problem, not other issues that others might find more important. -- 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}
