set_src_cost lying comment

[Jeff Law]

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.
>>
>> Jeff
>
> 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
>
> reg
>
> 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.

jeff