Re: set_src_cost lying comment

[Jeff Law <law at redhat dot com>]

On 06/21/2015 11:57 PM, Alan Modra wrote:
> set_src_cost says it is supposed to
> /* Return the cost of moving X into a register, relative to the cost
>     of a register move.  SPEED_P is true if optimizing for speed rather
>     than size.  */
>
> Now, set_src_cost of a register move (set (reg1) (reg2)), is zero.
> Why?  Well, set_src_cost is used just on the right hand side of a SET,
> so the cost is that of (reg2), which is zero according to rtlanal.c
> rtx_cost.  targetm.rtx_costs doesn't get a chance to modify this.
>
> Now consider (set (reg1) (ior (reg2) (reg3))), for which set_src_cost
> on rs6000 currently returns COSTS_N_INSNS(1).  It seems to me that
> this also ought to return zero, if the set_src_cost comment is to be
> believed.  I'd claim the right hand side of this expression costs the
> same as a register move.  A register move machine insn "mr reg1,reg2"
> is encoded as "or reg1,reg2,reg2" on rs6000!
Certainly seems inconsistent -- all the costing stuff should be 
revisited.  The basic design for costing dates back to the m68k/vax era.

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.

jeff