RE: set_src_cost lying comment

[Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>]

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Jeff Law
Sent: Wednesday, June 24, 2015 10:36 AM
To: gcc@gcc.gnu.org
Subject: Re: set_src_cost lying comment

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.

I have seen for target like Microblaze, making the changes in the cost of move instructions not same  at the chip level cost/latency improves 
the performance for Mibench/EEMBC benchmarks.  Also changing the cost of branch instruction and sometimes making it zero also improves
the performance for Mibench/EEMBC benchmarks.

>>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.

Thanks & Regards
Ajit

jeff