On Tue, Jun 23, 2015 at 11:05:45PM -0600, Jeff Law wrote: > I certainly agree that the cost of a move, logicals and arithmetic is > essentially the same at the chip level for many processors. But a copy has > other properties that make it "cheaper" -- namely we can often propagate it > away or arrange for the source & dest of the copy to have the same hard > register which achieves the same effect. > > So one could argue that a copy should have cost 0 as it has a reasonable > chance of just going away, while logicals, alu operations on the appropriate > chips should have a cost of 1.
That's an interesting point, and perhaps true for rtl expansion. I'm not so sure it is correct for later rtl passes where you'd like to discourage register moves.. Case in point: The rs6000 backend happens to use zero for the cost of setting registers to simple constants. That might be an accident, but when I fixed this by making (set (reg) (const_int)) cost one insn as it actually does for a range of constants, I found some call sequences regressesd. A call like foo(0,0) is better as (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (const_int 0)) li 4,0 (call ...) bl foo rather than (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (reg r3)) mr 4,3 (call ...) bl foo CSE will say the second sequence is cheaper if loading a constant is more expensive than a copy. In reality the second sequence is less preferable since you have a register dependency. A similar problem happens with foo(x+1,x+1) which currently emits (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (reg r3)) for the arg setup insns. On modern processors it would be better as (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (plus (reg x) (const_int 1))) So in these examples we'd really like register moves to cost one insn. Hmm, at least, moves from hard regs ought to cost something. -- Alan Modra Australia Development Lab, IBM
