This is the mail archive of the
mailing list for the GCC project.
Re: set_src_cost lying comment
- From: Jeff Law <law at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 23 Jun 2015 23:05:45 -0600
- Subject: Re: set_src_cost lying comment
- Authentication-results: sourceware.org; auth=none
- References: <20150622055710 dot GQ1723 at bubble dot grove dot modra dot org>
On 06/21/2015 11:57 PM, Alan Modra wrote:
Certainly seems inconsistent -- all the costing stuff should be
revisited. The basic design for costing dates back to the m68k/vax era.
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!
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.