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

[Richard Earnshaw <rearnsha at arm dot com>]

> >> 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.