[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 18 Mar 2015, aoliva at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
> 
> --- Comment #18 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
> (In reply to Jeffrey A. Law from comment #14)
> > So, forgive me, but is -DOPT supposed to be the good or the bad code?
> 
> It's the good one.  As noted in comment 12, I had that backwards in comment 6.
> 
> (In reply to Richard Biener from comment #15)
> > Because "coalescing" them doesn't do anything.  copyrename coalescing
> > assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR
> > the same.  But when both SSA_NAME_VARs are NULL this won't do anything.
> 
> This may be true when you look at only one pair of SSA names, but when you have
> 2 such candidate pairs involving one common SSA name, it can, and it does make
> a difference, as described in comment 6.
> 
> (In reply to Richard Biener from comment #16)
> > And as I analyzed in comment #3 we chose the now different coalescing because
> > it is more profitable (to the cost analysis we perform in out-of-SSA
> > coalescing).
> 
> No, we don't even *consider* the coalescing performed in the -DOPT case,
> because, as noted in comment 13, the SSA names ended up with different base
> names, because copyrename wouldn't give them the same base name.
> 
> (In reply to Richard Biener from comment #17)
> > To add to all this - IMHO copyrename should go
> 
> That's fine with me.
> 
> > Yes, out-of-SSA coalescing could be changed to allow coalescing of SSA names
> > with a user-DECL and anonymous SSA names (or SSA names with a DECL_IGNORED_P
> > decl).  But that will make the conflict graph much larger(?).
> 
> Ok, I'll give that a shot tomorrow (I'll be away for the whole day today).
> 
> > might happen that we end up coalescing things in a way
> > that there ends up being no DECL for a register and thus we lose in debug
> > quality (not sure if we could compensate by inserting debug stmts on the
> > edges to compensate for that - we couldn't do that if it requires splitting
> > the edge).
> 
> I'm not concerned about that.  Any debug stmts needed to make this work will
> already be in place, after the actual assignments, and after early PHI nodes. 
> Sure, edge insertions might separate the copies from the debug stmts inserted
> after the PHI nodes, but ultimately the bindings should take care of it.
> 
> > So to avoid wrong debug we'd have to always coalesce to an anonymous
> > entity
> 
> With debug stmts, we don't care what the base names are any more.  All the info
> we need (for tracked auto variables) is in the debug stmts.

But we do not always have debug stmts!

int bar (int b)
{
  int i;
  if (b > 7)
    i = b / 3;
  else
    return b * 4;
  return i;
}

is a testcase for what I am thinking of.  Hmm.  For some reason
into-SSA inserts a debug stmt, creating an extra copy _5 = i_4?!

  <bb 2>:
  if (b_2(D) > 7)
    goto <bb 3>;
  else
    goto <bb 4>;

  <bb 3>:
  i_4 = b_2(D) / 3;
  # DEBUG i => i_4
  _5 = i_4;
  goto <bb 5>;

  <bb 4>:
  _3 = b_2(D) * 4;

  <bb 5>:
  # _1 = PHI <_3(4), _5(3)>

so indeed we shouldn't lose anything here.  But are you sure
that we are never using REG_EXPR for debug?  With 
-fno-var-tracking-assignments for sure we do (I suppose we don't care),
at least var-tracking.c does look at REG_EXPR.