[PATCH] Alpha FIX REGISTER_MOVE_COST

[Richard Henderson]

On Mon, Feb 10, 2003 at 04:03:31AM +0100, Falk Hueffner wrote:
> as noted in PR optimization/8883, gcc is too eager to use FP registers
> with FIX. The reason is that REGISTER_MOVE_COST is 3 for moves between
> int and FP registers. That doesn't seem to be quite reasonable, since
> fp->int takes 3 cycles and int->fp 4, and the unit is "half cycles".
> So I suggest a value of 8 there. That improves the test case in the PR
> and speeds up bzip2 by a whopping 0.7%.

Which makes the cost higher than memory, which makes the
compiler not use FIX at all, does it not?  I'd argue that
(with the exception of stack slots) that using the fp
registers as sort of an L0 cache is useful.

Of course, I can see that with the old register allocator,
things can be very confused when it chooses bad assignments,
resulting in some significantly bad code.

Hmm.

The *real* problem is that reload refuses to re-construct
certain constants in integer registers, so we get

	(set (reg:DI int) (high:DI ...))
	(set (reg:DI fp) (reg:DI int))
	...
	(set (reg:DI int2) (reg:DI fp))
	(set (mem (lo_sum:DI (reg:DI int2) ...)) ...)

when we might as well have generated a new "high" pattern
in place of the copy into int2.

Lemme think about this for a bit.  It may be a decent
short-term solution for 3.3. and 3.4.



r~