On Fri, Oct 18, 2019 at 08:48:42PM +0100, Richard Earnshaw wrote: > > Consider this sequence during combine: > > Trying 18, 7 -> 22: > 18: r118:SI=r122:SI > REG_DEAD r122:SI > 7: r114:SI=0x1-r118:SI-ltu(cc:CC_RSB,0) > REG_DEAD r118:SI > REG_DEAD cc:CC_RSB > 22: r1:SI=r114:SI > REG_DEAD r114:SI
r122 is dead here. combine will have tried just 7+22 before, and that failed; it now only succeeds because the register copy is removed. All like you say and what your patch is about. But, this is a generic problem, that should be solved in combine itself (whether or not you also want to reduce the insn cost here). Maybe we should simply disallow pseudo-to-pseudo (or even all) copies when combining more than two insns, always? I'll experiment. > We don't want to prevent combine from eliminating such moves, as this > can expose more combine opportunities, but we shouldn't rate them as > profitable in themselves. We can do this be adjusting the costs > slightly so that the benefit of eliminating such a simple insn is > reduced. Yes, but combine should have removed the move in a 2->1 combination already, if it is beneficial: both 18->7 and 7->22 should have combined just fine. This also points to a potential target problem: why are those two combinations not allowed? Segher