Re: Basic infrastructure for substitution tracking

[Martin Jambor <mjambor at suse dot cz>]

Hi,

On Wed, Sep 23, 2009 at 05:42:18AM -0300, Alexandre Oliva wrote:
>
> ...
> 
> As for variables that currently aren't tracked by VTA...
> 
> For fully-scalarized variables (i.e., those for which a structure does
> not survive), each component variable could in in theory be handled as a
> VTA-trackable (one-part) variable, getting its own debug stmts and all.
> Nothing actually prevents SR decls from showing up in debug stmts,

Currently, they don't.  As far as I can tell, there's nothing that
should prevent them from successfully passing through
target_for_debug_bind, though.  In order to try having debug
statements for them, should I create them manually or do something
else?

> and
> all we have to do to deal with them properly at debug info generation
> time is to consolidate the location lists for each part of the aggregate
> source variable into a single location list.  AFAIK there's no reason to
> actually *combine* the separate parts into location list entries.  I.e.,
> for a variable of type struct { int a, b; }, we could emit location
> lists such as:
> 
> [PC1, PC2) <location for a> DW_OP_piece 4 [missing] DW_OP_piece 4
> [PC2, PC3) <location for a> DW_OP_piece 4 [missing] DW_OP_piece 4
> ...
> [PC1, PC3) [missing] DW_OP_piece 4 <location for b> DW_OP_piece 4
> [PC3, PC4) [missing] DW_OP_piece 4 <location for b> DW_OP_piece 4
> ...

Nice.

> 
> Partially-scalarized variables (i.e., those that retain an aggregate
> variable, and fields are extracted from or stored in it), similar
> arrangements could work, at least for the scalarized variables, that
> should get debug stmts when they get extracted or stored in the
> structure.  However, non-scalarized components might require more than
> an initial bind statement, for aliasing memory stores may cause the
> value binding to be invalidated.

I don't think so.  Intraprocedural SRA only operates on aggregates
which are not TREE_ADDRESSABLE and thus cannot have any accesses
through aliases.  (Still, the ideas below might prove interesting for
IPA-SRA).

Thanks,

Martin


> To deal properly with aliased memory
> locations, we'd need a location bind, rather than a value bind, so that
> memory stores don't invalidate the association between source name and
> memory location.  The alternative would be to emit additional debug
> stmts at every aliasing store, which would be wasteful.
> 
> As for non-scalarizable variables, these are always (?) addressable (no
> benefit from var-tracking, because their location is constant) or fully
> removed (could be handled just like fully-scalarized variables).  I can
> see how NONLOCALIZED vars could help improve debug info for the latter
> case, at least for as long as VTA can't deal with the scalarized cases.
> 
> -- 
> 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