So as I mentioned in the meeting last week, I've largely been ignoring
VTA (and more generally all debugging) issues with the reload work I'm
doing. It's time to rectify that situation.
For this phase of the work (range splitting) we only need to consider a
few straightforward transformations to the RTL and how they impact the
debugging information.
The goal is to take a pseudo P and break its live range down into P1,
P2, ... Pn where each of the sub-ranges are local to a region (right now
a region is a straight line hunk of code with no join nodes -- not quite
an extended basic block, but close). Outside these regions P lives in
memory. Within each region the new pseudos P1, P2, ... Pn may be
allocated to different hard registers.
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'm not terribly familiar with how dwarf2 represents variable ranges; I
tend to think of this as P living in memory, except during the
subregions where its in P1, P2, .. Pn. The sub-range pseudos P1, P2,
.. Pn all point back to P via ORIGINAL_REGNO and all have the same
reg_equiv_memory_loc.
So, without having looked closely at dwarf2out.c (it hurts my head every
time I try), is it likely we're going to need to be emitting new
debug_insns to describe how to correctly find P in the different contexts?
Thanks,
Jeff
- VTA/debugging vs reload-v2 Jeff Law
-
