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]

set_src_cost lying comment

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!

Continuing in the same vein, an AND is no more expensive than an IOR,
and similarly for other ALU operations.  So they all ought to cost
zero??  But this is ridiculous since set_src_cost is used as in many
places as the cost of an entire insn, eg. synth_mult compares the cost
of implementing a multiply as a series of adds and shifts against the
cost of a multiply.  If all those adds and shifts are costed at zero,
then synth_mult can't do its job.

So what should that comment say?

Alan Modra
Australia Development Lab, IBM

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