This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VTA/debugging vs reload-v2


On Apr  5, 2010, Jeff Law <law@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]