VTA/debugging vs reload-v2
Mon Apr 5 20:33:00 GMT 2010
On Apr 5, 2010, Jeff Law <email@example.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.
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.
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.
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.
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
More information about the Gcc