This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]