Re: GCC floating point usage

[Richard Earnshaw <rearnsha at arm dot com>]

> 	The PowerPC *BSD developers started discussing how to avoid using
> FPRs for integer moves.  Richard Earnshaw suggested bumping up
> MEMORY_MOVE_COST for FLOAT class and integer mode.  I needed to increase
> the cost quite high, but it does work.
> 
> 	There is some concern about this high an individual value causing
> a register preferences cost computation to overflow.  If this value were
> user-selectable and not the default, it might be reasonable for the
> PowerPC port.  It allows user control while avoiding multiple movdi
> patterns which could cause re-recognition problems.

Depending on how integer->float conversions are done this might lead to 
some rather strange code sequences, eg

	load	int_class <- [mem]
	move	float_class <- int_class
	convert float_class

rather than the more usual

	load	float_class <- [mem]
	convert float_class

In otherwords I think it would be necessary to keep 
	MEMORY_MOVE_COST (integer, FP_REGS) 
	   < (MEMORY_MOVE_COST (integer, GENERAL_REGS)
	      + REGISTER_MOVE_COST (FP_REGS, GENERAL_REGS))

I missed the start of the *BSD discussion, but if it's anything like the 
one that Mike is referring to that occurred on this list, then the issue 
is to discourage (severly) the first use of the floating point registers 
when there are no floating point operations in a function; otherwise we 
might pay a very large penalty in the kernel for the very first use and 
fairly large penalties after each context switch if the kernel switches 
the FP context on a lazy basis.

It seems to me that the best solution to this would be to have a new cost 
metric that expressed this discouragement directly, maybe 
CLASS_FIRST_USE_COST(class) which could then be set to a large value to 
express what really happens.  Once the threshold has been crossed the 
register allocator would then be free to use the registers as it would 
normally.

Maybe a cost metric of this nature could be considered for the new 
register allocator (it doesn't seem to be worth factoring it in to the old 
one).

R.