set_src_cost lying comment

[Jeff Law]

On 06/24/2015 03:18 AM, Alan Modra wrote:
> On Tue, Jun 23, 2015 at 11:05:45PM -0600, Jeff Law wrote:
>> 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.
>
> That's an interesting point, and perhaps true for rtl expansion.  I'm
> not so sure it is correct for later rtl passes where you'd like to
> discourage register moves..
It was the best I could come up with :-) I certainly don't know the 
history behind the choices.

>
> Case in point:  The rs6000 backend happens to use zero for the cost of
> setting registers to simple constants.  That might be an accident, but
> when I fixed this by making (set (reg) (const_int)) cost one insn as
> it actually does for a range of constants, I found some call sequences
> regressesd.  A call like foo(0,0) is better as
>    (set (reg r3) (const_int 0))	li 3,0
>    (set (reg r4) (const_int 0))	li 4,0
>    (call ...)			bl foo
> rather than
>    (set (reg r3) (const_int 0))	li 3,0
>    (set (reg r4) (reg r3))	mr 4,3
>    (call ...)			bl foo
> CSE will say the second sequence is cheaper if loading a constant is
> more expensive than a copy.  In reality the second sequence is less
> preferable since you have a register dependency.
Agreed 100%.

>
> A similar problem happens with foo(x+1,x+1) which currently emits
>    (set (reg r3) (plus (reg x) (const_int 1)))
>    (set (reg r4) (reg r3))
> for the arg setup insns.  On modern processors it would be better as
>    (set (reg r3) (plus (reg x) (const_int 1)))
>    (set (reg r4) (plus (reg x) (const_int 1)))
>
> 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.
Agreed again.  These are good examples of things the costing model 
simply wasn't ever designed to consider  -- because they weren't 
significant issues on the m68k, vax and other ports in the gcc-1 era.

So I don't really know how to tell you to proceed -- I've considered the 
costing models fundamentally flawed for many years, but haven't ever 
tried to come up with something that works better.

Jeff