> On Thu, 5 Mar 2009, Jan Hubicka wrote:
>
> > Hi,
> > this patch resulted from attempt to solve regression we have in
> > gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that
> > when
> > clonning function by ipa-cp we lose any information on function argument.
> > (and yes, it solves it)
> >
> > The gdb.opt/inline-locals.exp testsuite shows common pattern
> >
> > func (argument)
> > {
> > }
> >
> > otherfunc (otherargument)
> > {
> > func (otherargument);
> > }
> >
> > Where we now fully replace ARGUMENT by OTHERARGUMENT when inlining while
> > older
> > compilers actually substituted backwards, so ARGUMENT was available while
> > OTHERARGUMENT was not. This is quite irritating behaviour when trying to
> > debug since parameters of inlined functions tends to be lost.
> >
> > The patch adds mechanizm for tracking inline substitutions, so we
> > actually note that on whole scope of its existence ARGUMENT is having
> > same value as OTHERARGUMENT. This is represented by extending
> > NONLOCALIZED_VAR vector to contain optimized out declaration and it's
> > replacement
>
> ...
>
> This sounds like a simplified (only track parameter "coalescing") form
> of what we implemented on var-mappings-branch. As I see it would
> work well for wrapper functions, or rather in case either name ends
> up completely unused but will "break" once uses of both names
> persist. So, do you see any practical use besides C++ wrapper
I note substitution only for parameters that are completely replaced by
inliner, i.e. they are not set locally in function. That is only
in case we don't produce new declaration and copy statement, just
entry in NONLOCALIZED_VAR. I was thinking that perhaps I can also
handle case where parameter has more SSA names by noting the default
value and using DW_OP_default_value feature, but I am not sure it is
worth the effort and I guess var-mappings-branch or debug-branch
infrastructure shuld handle it.
The never modified function parameters are however quite case - you don't use
function parameter as
temporary variable most of time. So it works pretty well for GCC
sources (in fact it was about the main motivation that I tended to land
in tree-flow-inline and not having chance to inspect function
arguments).
It is not about wrapper functions, but also about parameters of
innermost function in the inline stack. For example in tree-ssa-ccp we
can track about 300 variables this way for most of the gimple
predicates:
{ Scope block #0
tree_code code;
static const char __FUNCTION__[23] = "gimple_assign_rhs_code";
{ Scope block #1202 (unused) ../../gcc/gimple.h:1832 Originating from :
static union tree_node * gimple_assign_rhs1 (const union gimple_statement_d *);
const union gimple_statement_d * gs = const union gimple_statement_d
*;replaced by:gs (nonlocalized)
{ Scope block #1203 (unused) Originating from :#0
static const char __FUNCTION__[19] = "gimple_assign_rhs1"; (nonlocalized)
{ Scope block #1204 (unused) ../../gcc/gimple.h:1730 Originating from :
static union tree_node * gimple_op (const union gimple_statement_d *, unsigned
int);
const union gimple_statement_d * gs = const union gimple_statement_d
*;replaced by:gs (nonlocalized)
unsigned int i = unsigned int;replaced by:1 (nonlocalized)
Without tracking we would get value of "gs" in the outer scope of the
function itself, but in inlined gimple_assign_rhs1 and gimple_op it
would end up optimized out.
Pre SSA inliner copmilers would behave other way, they would backward
propagate value to one of innermost inlined funcitions of "gs" but it
would not be available otherwise.
How would you expect to generate dwarf at the inlining time for those
variables? The substitutions has to combine in cascaded inlining and
has to be brought up to date for SRA and later get locations from RTL
land, so doing all this in in-memory dwarf structure seems bit
difficult..
Honza
> functions? Is it worth fixing them?
>
> Thanks,
> Richard.
