Re: set_src_cost lying comment

[Alan Modra <amodra at gmail dot com>]

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