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/25/2015 06:28 AM, Richard Earnshaw wrote:
On 24/06/15 17:47, Jeff Law wrote:
On 06/24/2015 03:18 AM, Alan Modra wrote:

So in these examples we'd really like register moves to cost one
insn.  Hmm, at least, moves from hard regs ought to cost something.
The more I think about it, the more I think that's a reasonable step.
Nothing should have cost 0.


It really means what you mean by cost here.  I think rtx_cost is really
talking about delta costs much of the time, so when recursing down

plus (op1, op2)

there's a cost from the plus, a cost from op1 and a cost from op2.

I believe the idea behind reg being cost 0 is that when op1 and op2 are
both registers in the above expression the overall cost is just the cost
of the plus, with no additional cost coming from the operands.
Perhaps, but it's also the case on the PPC and a variety of other architectures that there's no difference between a reg and some constants. And on some architectures the PLUS is no different than a logical operation or even a copy.

This leaves only one problem: if the entire expression is just


then the overall cost becomes zero.  We hit this problem because we only
look at the source cost, not the overall insn cost.  Mostly that's ok,
but in the specific case of a move instruction it doesn't really
generate the desired result.

Perhaps the best thing to do is to use the OUTER code to spot the
specific case where you've got a SET and return non-zero in that case.
Seems like it's worth an experiment.


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