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.
