VTA/debugging vs reload-v2

VTA/debugging vs reload-v2

[Jeff Law]

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

Re: VTA/debugging vs reload-v2

[Alexandre Oliva]

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

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

Re: VTA/debugging vs reload-v2

[Jeff Law]

On 04/05/10 14:32, Alexandre Oliva wrote:
> On Apr  5, 2010, Jeff Law<law@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

Re: VTA/debugging vs reload-v2

[Jakub Jelinek]

On Mon, Apr 05, 2010 at 05:18:35PM -0600, Jeff Law 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?

Yes, it can be arbitrary valid RTL (validate_change/verify_changes allow
any changes to DEBUG_INSNs).  The problematic stuff is mainly when some RTL
with non-VOIDmode (REG, MEM etc.) needs to be replaced with a VOIDmode
constant - in that case simplify_replace_{,fn_}rtx needs to be used to
change the invalid RTL into valid.  We don't want say
(zero_extend:DI (const_int 6)) or (subreg:QI (const_int 12345678) 4) etc.
staying around in the DEBUG_INSNs.  But I guess for reload2 you'll be
changing just REGs and MEMs to other REGs and MEMs - in that case
just a replacement through say for_each_rtx is possible too.

	Jakub

Re: VTA/debugging vs reload-v2

[Jeff Law]

On 04/06/10 00:35, Jakub Jelinek wrote:
> On Mon, Apr 05, 2010 at 05:18:35PM -0600, Jeff Law 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?
>>      
>    The problematic stuff is mainly when some RTL
> with non-VOIDmode (REG, MEM etc.) needs to be replaced with a VOIDmode
> constant - in that case simplify_replace_{,fn_}rtx needs to be used to
> change the invalid RTL into valid.
These shouldn't be a problem.


>     But I guess for reload2 you'll be
> changing just REGs and MEMs to other REGs and MEMs - in that case
> just a replacement through say for_each_rtx is possible too.
>    
Yea, we're going to have to walk down the expression with for_each_rtx 
searching for REGs, then see if the REG we found needs replacing.  
Handling narrowing SUBREGs makes this marginally more complex, but it's 
still manageable.  I just wanted to be sure there that there weren't any 
assumptions I could make to simplify the code :-)

jeff

Re: VTA/debugging vs reload-v2

[Jakub Jelinek]

On Tue, Apr 06, 2010 at 09:23:09AM -0600, Jeff Law wrote:
>>     But I guess for reload2 you'll be
>> changing just REGs and MEMs to other REGs and MEMs - in that case
>> just a replacement through say for_each_rtx is possible too.
>>    
> Yea, we're going to have to walk down the expression with for_each_rtx  
> searching for REGs, then see if the REG we found needs replacing.   
> Handling narrowing SUBREGs makes this marginally more complex, but it's  
> still manageable.  I just wanted to be sure there that there weren't any  
> assumptions I could make to simplify the code :-)

As soon as you start doing simplifications, I'd say simplify_replace_fn_rtx
is the way to go.  In its current implementation, the callback is called on
each of the rtxs like with for_each_rtx.  Whenever you need to replace
something, you just return the replacement, otherwise return NULL meaning
no changes are needed.  The result is gong to be simplified only
when some argument of a rtx has actually changed.

	Jakub

Re: VTA/debugging vs reload-v2

[Alexandre Oliva]

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