On Nov 24, 2007 5:54 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > 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.
So we get a "third way". GCC has insns and notes, and now it gets a third object to deal with in the insns stream. And it has to handle this new case everywhere. To me it seems that your approach will not help to make GCC easier to work with and understand. Unless there are compelling reasons to do this, I think this is a step in the wrong direction. > > 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. I didn't say "complex conditionals" but ugly conditionals ;-) I mean all the "INSN_P && ! DEBUG_INSN_P" conditionals. There seem to be a lot of those, and it's not immediately obvious where and when you'd need them. > > 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. Ah! More on that later. > > 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? Ah, there you go again with this extremist pro-debug-info stance. How can one argue with you when you keep ridiculing other points of view using ridiculous arguments? Who said anything about "generating more incorrect information just for the sake of it"? I don't think anyone did. The "for the sake of it" part is just offensive. You seem imply that people are arguing gcc should emit wrong debug information on purpose. Please step out of your own world of thoughts for a second, and try to understand that other people can have a different but nevertheless reasonable point of view. I think it is impossible to get perfect debug info after very complex code transformations. And because of that, I also think it is reasonable to not get perfect debug info in less complex cases. Your colleague expressed perfectly how I define "sufficiently good debug info": "It needs to be good enough that a semi-knowledgable person or a dumb but heuristic-laden program that processes debugging info can nevertheless extract reliable information." (http://gcc.gnu.org/ml/gcc/2007-11/msg00581.html) Note how this "good enough" does not imply correctness at all cost". Here is another "extremist" point of view: Correctness for a optimization algorithm means that it does not miss optimization opportunities that it is designed to catch. Therefore if an optimization algorithm implementation misses an optimization that it should catch, then this is a correctness issue. ;-) You said you now get the same code with and without -fvar-tracking-assignments on your branch. Can you also prove that the branch does not introduce new missed optimizations wrt. the latest revision that you merged from the trunk? Gr. Steven
