On Apr 5, 2010, Jeff Law <l...@redhat.com> wrote: > On 04/05/10 14:32, Alexandre Oliva wrote: >> 2. When renaming references from P to P' in a region, do take debug >> insns in the region into account, renaming references in debug insns as >> you would in any other insn.
> OK. So presumably the 2nd argument in a VAR_LOCATION can be any rtl > expression? Meaning I have to parse it looking for things that need > changing? Right? If DU can't help you get straight to them, yeah. > Or I might be able to get away with changing regno_reg_rtx to point to > the appropriate memref... +1 > Everything you noted seems to be designed to keep the existing > debug_insns updated -- under what circumstances are debug_insns > created (which ought to give me a clue about whether or not I'm going > to need to create new ones). You don't. debug insns are created out of debug stmts, created only at points in which a user variable changes values: at assignments and at confluences between possibly-different values (PHI nodes). There's no need to emit debug insns at loads or stores. Value tracking will realize, at the load and at the store, that the same value is in both operands at the end of the instruction, and will automatically issue debug notes as needed. ATM, the “as needed” is taken a bit too literally: only when a location for a variable or sub-expression dies is another location computed; some day we'll produce complete information, with *all* locations in which the value of a variable is stored. We may then have to be able to tell whether or not a location is shared with other variables, and if so, whether it's an LVALUE or RVALUE, so to speak, for each variable that refers to it. > FWIW, I don't see any references to debug_insn or var_location in > gcc/doc/*.texi. Somehow I think this must be unintentional. Indeed. Now that we're out of P1 VTA bugs for 4.5, I'll make it a priority to come up with something. Thanks! -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
