[PATCH] Fix PR47801, fold references in debug stmts

[Richard Guenther]

On Sat, 19 Feb 2011, Jakub Jelinek wrote:

> On Sat, Feb 19, 2011 at 09:57:06PM +0100, Richard Guenther wrote:
> > > I'd say this is done in a wrong spot, because if gimple_debug_bind_get_value
> > > is say PLUS_EXPR of a VAR_DECL and INTEGER_CST, you wouldn't fold the
> > > VAR_DECL.
> > 
> > I thought we have the same restrictions on debug stmt RHS as on
> > gimple RHS, thus memory refs always get a debug temp?
> 
> Not sure if always, but probably at least most of the time.
> int m = 7;
> int main (void)
> {
>   int a = m;
>   int b = m + 1;
>   int c = m * 4;
>   int *d = &m;
>   return 6;
> }
> 
> (wonder if we shouldn't do some simple CSE on the debug temporaries...).

Yeah, also DCE ...

> > > Can't this be done at the beginning of expand_debug_expr instead (in the
> > > switch based on TREE_CODE_CLASS you'd for
> > >   case tcc_declaration:
> > >   case tcc_reference:
> > > do this folding and if you decide to use the folded value, you'd just
> > > return expand_debug_expr (folded);
> > 
> > Well, from a quick look I think we'll end up recursing from ADDR_EXPRs
> > which will break.
> 
> It wouldn't break, we'd just generate DW_OP_GNU_implicit_ptr, but if the
> const has a memory it is of course preferrable to use real address of the
> object.  We'd have to pass an extra bool whether we are in ADDR_EXPR or not
> (i.e. whether we are trying hard to get a MEM or not).  Anyway, given the
> above I guess your patch is better (Alex, do you agree?).

It at least looked like the most localized place to fix this given
that we're in stage4.  It is after all mostly to fixup "regressions"
that show up because of my last LTO debug fixes.

Richard.