Re: PR 23551: why should we coalesce inlined variables?

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2007-07-09 at 16:11 -0300, Alexandre Oliva wrote:
> On Jul  9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
> 
> > On Mon, 2007-07-09 at 14:44 -0300, Alexandre Oliva wrote:
> merit.
> 
> But it's the same test condition, and the same testcase, after some
> minimal manipulation.  This is enough of a reason for me to coalesce
> it.  http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00739.html

no it isn't. I'd reject that patch too, then the patch doesnt get
reverted.

Did you even look at the debug info that gives you? I can guarantee you
PRs for that.

something simple which contains a copy will wreck debug info in a
serious way:
 int a,b;

  a = c1();
  b = c1();
  if (b < 10)
    b = a;
  c2 (b);
  return b;

will result in the base for 'b' being renamed to 'a', then a new 'a'
created because they cant coalesce:

  a = c1 ();
  a.26 = c1 ();
  if (a.26 <= 9)
    goto <bb 4>;
  else
    goto <bb 3>;
<bb 3>:
  a = a.26;
<bb 4>:
  c2 (a);
  return a;

we can at least avoid that.

 At least we get some things right now. That patch will be making more
things wrong, a step in the wrong direction, and you can't be seriously
promoting that as a solution.  Copies between user variables are much
rarer.  This change would result in ALL copies between user variables
changing the debug names, even if a coalesce doesnt happen. Rememeber,
copyrename doesn't actually PERFORM coalescing, it simple changes base
names to allow coalescing to possible happen.

This is why separating base names from debug names would be so helpful.
we could then TRY this patch. copyrename would change the base name, but
he debug info would remain separate. if they don't coalesce, the the
debug info is still right. Thats really all that is keeping that from
happening right now...  It resolves all the problems that copyrename
introduces.   THEN we can deal with other debugging issues.

Andrew