This is the mail archive of the
mailing list for the GCC project.
RE: set_src_cost lying comment
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Jun 2015 15:40:03 +0000
- Subject: RE: set_src_cost lying comment
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 22.214.171.124) smtp.mailfrom=xilinx.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;
- References: <20150622055710 dot GQ1723 at bubble dot grove dot modra dot org> <558A3AA9 dot 6090406 at redhat dot com>
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jeff Law
Sent: Wednesday, June 24, 2015 10:36 AM
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