On 04/05/10 14:32, Alexandre Oliva wrote:
On Apr 5, 2010, Jeff Law<l...@redhat.com> wrote:
We accomplish this by emitting a load from memory into a new pseudo
before the first use of P in a region and a store from the new pseudo
back to memory after the last assignment to P within the region, then
we rename all references from P to P'. It's marginally more complex,
but I think for this discussion the other complexities can be ignored.
After all regions have been processed, P is gone from the insn stream.
Obviously P can be found in memory, P1, P2, ... Pn depending on
precisely where we are in the code when the value is P is requested.
I can think of 3 points that you might have to be concerned about:
1. Don't pay attention to debug insns when computing the live ranges.
You don't want to take debug insns into account when making decisions
about transformations to executable code.
Right. I already figured this one out the hard way a while back.
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?
3. If any debug insns ended up outside any of the regions determined
without taking debug insns into account, you may have to patch things up
so that they don't remain as dangling pointers to P. From your
description above, it appears to me that replacing such remaining
references to P in debug insns with the memory slot assigned to it would
be the right thing to do.
Makes sense, though I'm not terribly familiar with how this could
happen, replacing P with its memory location seems to be the right thing
to do. I guess a single pass through the entire function's RTL looking
for dangling references in debug insns is in order. Or I might be able
to get away with changing regno_reg_rtx to point to the appropriate
memref... hmmm.
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).
This should be all, and it's very much in line with “The Zen of VTA”:
disregard debug insns when deciding what to do, transform debug insns
just as you would regular insns, and patch up any debug insns left out
of the decisions you made.
FWIW, I don't see any references to debug_insn or var_location in
gcc/doc/*.texi. Somehow I think this must be unintentional.
Jeff
