Re: ppc64 floating point usage

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Zack Weinberg writes:

Zack> Would you please explain this in more detail?  What do you think the
Zack> problem is, and the correct fix?

	The problem is FPRs allocated in functions which do not perform
any floating point computations.  Making it less likely that FPRs will be
allocated is not an acceptable solution because that is not a guarantee of
correct behavior and simply gives programmers a false sense of confidence.
If it does not produce the expected result 100% of the time, it is useless
for the programmers who truly require that functionality.

	The use of FPRs as the DImode output for float to int conversion
patterns should not contribute to the regclass preference for those
pseudos.  The previous patch was not only for a reload problem.

	I am sorry that a hardware manufacturer used the wrong options to
compile a PPC64 Linux kernel driver and the mistake was not detected
automatically.  However, the patches in this thread are not going to
prevent it from happening again, they just makes it less likely -- which
is even worse.  The correct compiler option still is necessary, but now it
sometimes will work without the option, which will cause more confusion
due to the seemingly random failures and superstition about options.

	The correct fix is for the compiler to automatically determine
whether the function performs any floating point computations and then
modify register allocation appropriately, e.g., make FPRs fixed just prior
to register allocation if they should not be used.

David