Alexandre Oliva <[EMAIL PROTECTED]> writes: > So... The compiler is outputting code that tells other tools where to > look for certain variables at run time, but it's putting incorrect > information there. How can you possibly argue that this is not a code > correctness issue?
I don't see any point to going around this point again, so I'll just note that I disagree. > >> >> > We've fixed many many bugs and misoptimizations over the years due to > >> >> > NOTEs. I'm concerned that adding DEBUG_INSN in RTL repeats a mistake > >> >> > we've made in the past. > >> >> > >> >> That's a valid concern. However, per this reasoning, we might as well > >> >> push every operand in our IL to separate representations, because > >> >> there have been so many bugs and misoptimizations over the years, > >> >> especially when the representation didn't make transformations > >> >> trivially correct. > >> > >> > Please don't use strawman arguments. > >> > >> It's not, really. A reference to an object within a debug stmt or > >> insn is very much like any other operand, in that most optimizer > >> passes must keep them up to date. If you argue for pushing them > >> outside the IL, why would any other operands be different? > > > I think you misread me. I didn't argue for pushing debugging > > information outside the IL. I argued against a specific > > implementation--DEBUG_INSN--based on our experience with similar > > implementations. > > Do you remember any other notes that contained actual rtx expressions > and expected optimization passes to keep them accurate? No. > Do you think > we'd gain anything by moving them to a separate, out-of-line > representation? I don't know. I don't see such a proposal on the table, and I don't have one myself, so I don't know how to evaluate it. Ian
