https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #22 from Jeffrey A. Law <law at redhat dot com> --- Let's try to stay focused. Killing copyrename seems like a fine thing to do as long as the resulting debug info is good. But that's independent of this BZ. I still find myself wondering if leaving the "0" instead of "_10" in that PHI node is a reasonable approach. Certainly if I hack uncprop to leave things in that state, I get the code we want. And ISTM that uncprop ought to leave the constant alone if the SSA_NAME holding the constant conflicts with any of the other SSA_NAMEs in the PHI node that may potentially coalesce with the PHI result. That captures pretty well the case where the constant is better than an SSA_NAME. In this particular case, we have: # _28 = PHI <0(2), _29(3), _29(7), _10(8), _29(6)> When _28 and _10 coalesce, the result then conflicts with _29 during IRA/LRA because of the extended lifetime of _10). Thus the annoying copies created by out-of-ssa can't be eliminated. WIth the proposed change, we'd instead have: # _28 = PHI <0(2), _29(3), _29(7), 0(8), _29(6)> While we won't coalesce _28/_29 during out-of-ssa, LRA will see the copies and note that the associated pseudos don't conflict and ultimately assign them to the same hard register and the annoying copies are gone.
