Re: Basic infrastructure for substitution tracking

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> Ok, so this is equivalent to inserting DEBUG_STMTs for all param decls
> in the caller at the start of the callee copy.  But it is cheaper
> because when that function is inlined we don't copy those DEBUG_STMTs
> but instead via NONLOCALIZED_VARS we know they were the same.

Yes, additionally we don't go to RTL with NONLOCALIZED_VARS and don't
var track them, just use the location lists produced for variables they
reffer to. Since NONLOCALIZED_VARS are on-side they are not referring to
SSA name, but to user variables themselves.
> 
> Now I see you actually adjust the DECL_VALUE_EXPRs and unshare the
> expression at some point.  But this will adjust all inlined-to
> copies which is not correct?

I must check, it is probably bug.
> 
> I am btw confused by your re-using of DECL_VALUE_EXPR -- that might
> be already in use, and in this patch I see you only ever set it if
> it was already set which obviously cannot be everything required?

Yes, I use NONLOCALIZED_VARS only in inliner code, because every time
we completely replace some declaration, we also know we don't want
to copy it.

VALUE_EXPR is used by Martin's SRA code where both the new replacement
and original declaration might stay in the code.  I can break this up
further (i.e. do nonlocalized bits first).  We won't previously have
VALUE_EXPR there.

I originally didn't used VALUE_EXPR for neither, but then I noticed that
our current VALUE_EXPR code is semi-broken given that after inlining we
don't copy the VALUE_EXPRs and thus we lose the debug info. Currently
DECL_VALUE_EXPR is used to track VLA arrays and nested functions. In
both cases we need VALUE_EXPRs to be updated same way as I handle them
now.  So that part of patch is more a bugfix.
> 
> I am concerned by all the duplicating of what DEBUG_STMTs can do
> (the instantiation and the substitution) - it adds a lot of code.

I would hope for more code sharing too, given they they are semantically
same, but I was not able to find code I needed.

longer hunks of code are basically the simplify_value bits that in my
understanding don't exist in DEBUG_STMT basically since DEBUG_STMTs are
trying to track everything including temporaries and when temporary is
going away, the users of it are updated right?  This is bit difficult
with the on-side datastructure since we don't maintain any use links
from variables to debug_stmts...

Other longer chunk is removal of invalidated replacements in
tree-ssa-live.  This is basically there to handle SRA constructors in
nice way (i.e. when one part of constructor become dead it does not mean
that everything did).  Where we track useless debug stmts? In DCE?

> Doesn't the substitution code in tree-ssa-live.c have the same
> problem as DEBUG_STMTs, exponential growth of expression size?

Well, VALUE_EXPR are set for SRAed variables, there expressions are not
nested so we don't get growth.  With VALUE_EXPRs comming from VLAs we
never refer to the decl in function body, so they won't get chained.

On the ohter hand inliner can chain substitutions i.e. when inlining
function with already recorded subtitution.   This is same as with
DEBUG_STMTs.

But as I was looking into what hapens with DEBUG_STMT it seems that we
are just broken here.  We seem to track well the replacements down to
RTL but we produce two different declarations - one used in DEBUG_STMT
other used in the debug info, so we don't get any dwarf.  Will try to
fix this.

Honza