rfc: replacing fp-bit with glibc's soft-fp implementation

rfc: replacing fp-bit with glibc's soft-fp implementation

[Aldy Hernandez]

I've talked with this over with Geoff and Richard on and off over the 
past few months, and I've finally decided to give it a go.  Before I 
sink any time into it, I'd like to get people's input, to make sure 
there are no objections.

Glibc's soft-fp/ implementation (also used in the Linux kernel) is both 
faster, and more accurate.  Not to mention, it also provides exceptions 
and rounding modes.

If done right in both glibc and gcc, we can even provide a completely 
soft float implementation that is IEEE/ISO compliant for systems that 
have no hardware floating point.  We would of course have to define an 
interface between libgcc and glibc to set rounding modes and exceptions.

There is a thread about this on the glibc list a while back, when I was 
writing a completely soft float implementation for PPC glibc.  The 
interesting bits are here:

	http://sources.redhat.com/ml/libc-alpha/2002-11/msg00044.html

I was thinking we could migrate back ends one at a time to the soft-fp/ 
implementation, and remove the fp-bit stuff once all the back ends are 
migrated.  The reason I mention this is because of the _FP_DIV*, _FP_* 
macros that each back end will need to provide.

Anywhoo, the details are a bit sketchy, but I wanted to bring this up, 
to see what everyone else thought.

Thoughts?

Aldy

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Richard Earnshaw]

> I've talked with this over with Geoff and Richard on and off over the 
> past few months, and I've finally decided to give it a go.  Before I 
> sink any time into it, I'd like to get people's input, to make sure 
> there are no objections.
> 
> Glibc's soft-fp/ implementation (also used in the Linux kernel) is both 
> faster, and more accurate.  Not to mention, it also provides exceptions 
> and rounding modes.

Can these be disabled if a user wants faster code, or has code that relies 
on behaviour such as flush-to-zero and no-nans?

> If done right in both glibc and gcc, we can even provide a completely 
> soft float implementation that is IEEE/ISO compliant for systems that 
> have no hardware floating point.  We would of course have to define an 
> interface between libgcc and glibc to set rounding modes and exceptions.

I'm in favour of anything that improves the FP emulation performance (who 
wouldn't be?) but there is a potential stumbling block in that the code 
you are replacing is GPL with exception, while presumably the code in 
glibc is LGPL.  Has the suggestion been cleared with RMS?

Finally, this "interface" you mention also needs to work when the C 
library is not glibc, particularly in the embedded space.

R.

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Aldy Hernandez]

>> faster, and more accurate.  Not to mention, it also provides 
>> exceptions
>> and rounding modes.
>
> Can these be disabled if a user wants faster code, or has code that 
> relies
> on behaviour such as flush-to-zero and no-nans?

By user, do you mean at runtime, or at library build time?  At build 
time, it's pretty easy:

	#define FP_SET_EXCEPTION /*NOTHING*/
	#define FP_UNSET_EXCEPTION /*NOTHING*/
	#define FP_CLEAR_EXCEPTIONS /*NOTHING*/
	#define FP_DECL_EX /*NOTHING*/
	#define FP_HANDLE_EXCEPTIONS /*NOTHING*/
	#define FP_ROUNDMODE FP_RND_ZERO
	etc

If you mean at runtime ala "gcc -msoft-float -mfast-soft-float", then 
that functionality would have to be added.  Perhaps we could provide 
fast soft float libraries and slower-but-accurate soft float libraries. 
  Or set accuracy off by default, and provide hooks in both newlib and 
glibc to enable exceptions, nans, and rounding.

...but I don't like either of these [runtime] approaches.  Although we 
need to actually benchmark the current fp-bit implementation and 
glibc's soft-fp implementation, I'm willing to bet that glibc's is 
faster, even while handling exceptions and nans.

> I'm in favour of anything that improves the FP emulation performance 
> (who
> wouldn't be?) but there is a potential stumbling block in that the code
> you are replacing is GPL with exception, while presumably the code in
> glibc is LGPL.  Has the suggestion been cleared with RMS?

Ah.  Very good point.  No, I haven't brought it up with RMS, but I can 
do that in a follow up email.

> Finally, this "interface" you mention also needs to work when the C
> library is not glibc, particularly in the embedded space.

Yup.

Aldy

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Richard Earnshaw]

> >> faster, and more accurate.  Not to mention, it also provides 
> >> exceptions
> >> and rounding modes.
> >
> > Can these be disabled if a user wants faster code, or has code that 
> > relies
> > on behaviour such as flush-to-zero and no-nans?
> 
> By user, do you mean at runtime, or at library build time?  At build 
> time, it's pretty easy:
> 
> 	#define FP_SET_EXCEPTION /*NOTHING*/
> 	#define FP_UNSET_EXCEPTION /*NOTHING*/
> 	#define FP_CLEAR_EXCEPTIONS /*NOTHING*/
> 	#define FP_DECL_EX /*NOTHING*/
> 	#define FP_HANDLE_EXCEPTIONS /*NOTHING*/
> 	#define FP_ROUNDMODE FP_RND_ZERO
> 	etc
> 
> If you mean at runtime ala "gcc -msoft-float -mfast-soft-float", then 
> that functionality would have to be added.  Perhaps we could provide 
> fast soft float libraries and slower-but-accurate soft float libraries. 
>   Or set accuracy off by default, and provide hooks in both newlib and 
> glibc to enable exceptions, nans, and rounding.
> 
> ...but I don't like either of these [runtime] approaches.  Although we 
> need to actually benchmark the current fp-bit implementation and 
> glibc's soft-fp implementation, I'm willing to bet that glibc's is 
> faster, even while handling exceptions and nans.

I think generally it would be a compile-time option -- it would cause gcc 
to link in a different version of libgcc.a.

There are several reasons for wanting to do it, but most generally boil 
down to speed and code size.

BTW flush-to-zero normally means flush denormals to zero, not FP_ROUNDMODE.

> 
> > I'm in favour of anything that improves the FP emulation performance 
> > (who
> > wouldn't be?) but there is a potential stumbling block in that the code
> > you are replacing is GPL with exception, while presumably the code in
> > glibc is LGPL.  Has the suggestion been cleared with RMS?
> 
> Ah.  Very good point.  No, I haven't brought it up with RMS, but I can 
> do that in a follow up email.

Any discussion on the technicals is academic if we don't have permission 
to import the code, so I suggest we sort that out first.

R.

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Hans-Peter Nilsson]

On Fri, 28 Feb 2003, Aldy Hernandez wrote:
> I've talked with this over with Geoff and Richard on and off over the
> past few months, and I've finally decided to give it a go.  Before I
> sink any time into it, I'd like to get people's input, to make sure
> there are no objections.

Consider tege's fp-bit replacement posted some years(! 1999?)
ago that was said to be a substantial speed and conformance
improvement.  (Nobody commented at the time.)  If it's also
smaller than glibc:s implementation, it should be chosen
instead.

brgds, H-P

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Jim Wilson]

Hans-Peter Nilsson wrote:
> Consider tege's fp-bit replacement posted some years(! 1999?)

July 15, 1999.  I saved a copy of it.
http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html

It is smaller and faster and less buggy than fp-bit.  I haven't looked 
at the glibc FP code, but I suspect it is bigger than Torbjorn's code, 
since Torbjorn's code doesn't try to handle exceptions. For speed and 
reliability, they are probably comparable.

Jim

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Jim Wilson]

There is also a copy of fp-bit in the gdb simulator, slightly modified, 
and a bit out of date.  See gdb src/sim/common/sim-fpu.c.  It would be 
nice if we could fix both the gcc and gdb simulator FP emulation 
problems at the same time.

Jim

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Aldy Hernandez]

On Sun, Mar 09, 2003 at 12:04:54PM -0500, Hans-Peter Nilsson wrote:
> On Fri, 28 Feb 2003, Aldy Hernandez wrote:
> > I've talked with this over with Geoff and Richard on and off over the
> > past few months, and I've finally decided to give it a go.  Before I
> > sink any time into it, I'd like to get people's input, to make sure
> > there are no objections.
> 
> Consider tege's fp-bit replacement posted some years(! 1999?)
> ago that was said to be a substantial speed and conformance
> improvement.  (Nobody commented at the time.)  If it's also
> smaller than glibc:s implementation, it should be chosen
> instead.

Rms is still pondering over the licenses, so I'm going to do as Earnshaw
suggested, and wait for the verdict before discussing technical details.
But if you post a link to tege's replacement, I'll take a look at it.

Aldy

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Aldy Hernandez]

On Sun, Mar 09, 2003 at 03:24:34PM -0500, Jim Wilson wrote:
> There is also a copy of fp-bit in the gdb simulator, slightly modified, 
> and a bit out of date.  See gdb src/sim/common/sim-fpu.c.  It would be 
> nice if we could fix both the gcc and gdb simulator FP emulation 
> problems at the same time.

If the gdb folks want to join in, I'd be more than happy to provide
assistance, but I doubt I'll have time or energy to post the corresponding
gdb patches.

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[David Edelsohn]

>>>>> Aldy Hernandez writes:

Aldy> Rms is still pondering over the licenses, so I'm going to do as Earnshaw
Aldy> suggested, and wait for the verdict before discussing technical details.
Aldy> But if you post a link to tege's replacement, I'll take a look at it.

	Jim posted a link earlier in this thread:

http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html

I would recommend Tege's version as well.

David

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Hartmut Schirmer]

Jim Wilson wrote:
> Hans-Peter Nilsson wrote:
> > Consider tege's fp-bit replacement posted some years(! 1999?)
>
> July 15, 1999.  I saved a copy of it.
> http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
>
> It is smaller and faster and less buggy than fp-bit.  I haven't looked
> at the glibc FP code, but I suspect it is bigger than Torbjorn's code,
> since Torbjorn's code doesn't try to handle exceptions. For speed and
> reliability, they are probably comparable.

I gave it a try on SH-1. Worked just out of the
box and is about 3 times faster than the fp-bit version :-)

Hartmut

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Aldy Hernandez]

On Monday, March 10, 2003, at 03:07  PM, David Edelsohn wrote:

>>>>>> Aldy Hernandez writes:
>
> Aldy> Rms is still pondering over the licenses, so I'm going to do as 
> Earnshaw
> Aldy> suggested, and wait for the verdict before discussing technical 
> details.
> Aldy> But if you post a link to tege's replacement, I'll take a look 
> at it.
>
> 	Jim posted a link earlier in this thread:
>
> http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
>
> I would recommend Tege's version as well.

RMS just mailed me saying he approved of the licensing discrepancy: 
that we could use glibc's soft float emulation in libgcc.

I guess we can start the technical discussions again.

Some folks have suggested using Tege's version.  Jim mentioned it was 
probably comparable for speed and reliability, yet being smaller.  
However, Tege's version doesn't handle exceptions which was one of my 
main reasons for using glibc's code.

Any further input?  If folks are still interested in Tege's version 
perhaps I should start hacking up some sample programs with statistics 
so we can compare size, speed-- both with and without exceptions.

Aldy

Re: rfc: replacing fp-bit with glibc's soft-fp implementation

[Richard Henderson]

On Tue, Apr 15, 2003 at 09:24:49AM -0400, Aldy Hernandez wrote:
> Any further input?  If folks are still interested in Tege's version 
> perhaps I should start hacking up some sample programs with statistics 
> so we can compare size, speed-- both with and without exceptions.

Please do.  Without these numbers we can't evaluate easily.
Also, post the resulting programs so that folks can build
them for other embedded targets and see if there's variance there.


r~