ppc64 floating point usage [was Re: PPC64 Compiler bug !!]

[Michael Meissner]

On Fri, Jun 13, 2003 at 04:07:45PM -0500, Michael S. Zick wrote:
> On Friday 13 June 2003 04:02 pm, linas@austin.ibm.com wrote:
> > On Fri, Jun 13, 2003 at 04:09:06PM -0400, David Edelsohn wrote:
> >
> > Bird in hand vs. two in the bush.  We have Alan Modra's patch now, we
> > don't have an acceptable -mno-implicit-float patch.
> >
> > There is concern that Alan's patch will negatively impact performance
> > of fp code.  Is there a way to unambiguously resolve this issue, or
> > at least resolve it to everyones satisfaction?
> >
> A patch for a related issue just appeared for gas-arm-Linux and
> gas-arm-NetBSD...
> <http://sources.redhat.com/ml/binutils/2003-06/msg00494.html>
> <http://sources.redhat.com/ml/binutils/2003-06/msg00497.html>
> 
> Perhaps a similar route could be followed (I.E: -mfpu=none) to
> support developers that need the "never, ever, for any reason"
> touch the fp registers.

Ummm, you already have that, it is spelled -msoft-float.  I don't understand
what a separate switch buys you.

> I imagine that option would just select a register/mode description
> that does not mention fp registers. Ports might have to add 
> descriptor support for this option.

Ummm, one of the earlier messages stated this furor came about because a driver
writer did not use the -msoft-float option.  If they are going to neglect using
a switch that has been used by the Linux kernel for at least 4 years for all of
its PowerPC builds (for precisely this reason BTW), I can't really imagine them
using any new switch.

Note, at least a few years ago, getting USER space code to use floating point
registers to speed up structure moves (since using the FP registers is the only
way to move 64 bits at a time in a 32 bit environment) was a big deal.  I am
worried that if we change the compiler, we may be be slowing down these
programs.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org