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
