This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend

On Feb 9, 2012, at 10:28, Richard Guenther wrote:
> Yes, definitely!  OTOH last time I added the toplevel libgcc-math directory
> and populated it with sources from glibc RMS objected violently and I had
> to remove it again.  So we at least need to find a different source of
> math routines to start with (with proper licensing terms).
Right, I new there had been issues like this with the glibc stuff.
While I'm open to trying to deal with RMS on this, we indeed might want
to go a different route. So much for free software.
> I'd definitely like to see this library also to host vectorized routines and
> provide a myriad of entry-points.
Exactly. In particular, I'd expect to see dozens of variations of some
important performance-sensitive functions like sin and cos, while others
will just have one reasonably accurate machine-independent reference

> So - do you have an idea what routines we can start off with to get
> a full C99 set of routines for float, double and long double?  The last
> time I was exploring the idea again I was looking at the BSD libm.

I would think fdlibm might be a good starting point for double. I don't
know of any appropriately licensed library that provides good functions
for all types.

Maybe the answer is to provide an infrastructure to start adding
functions, falling back on libm where needed. We'll need to think
about how to accommodate multiple versions with varying accuracy
and speed and how to select from these.

I think it would make sense to have a check list of properties, and
use configure-based tests to categorize implementations. These tests
would be added as we go along.


 [ ] Conforms to C99 for exceptional values 
     (accepting/producing NaNs, infinities)

 [ ] Handles non-standard rounding modes,
     trapping math, errno, etc.

 [ ] Meets certain relative error bounds,
     copy from Ada Annex G numerical requirements
     (typically between 2 eps and 4 eps for much of range)

 [ ] Guaranteed error less than 1 ulp over all arguments,
     typical max. error close to 0.5 ulp.

 [ ] Correctly rounded for all arguments

While I think it would be great if there were a suitable
GNU libm project that we could directly use, this seems to only
make sense if this could be based on the current glibc math
library. As far as I understand, it is unlikely that we
can make this happen in the near future.

However, even if that were possible, I think it is necessary for 
us to be able to inline math functions directly in user programs, 
without those programs having to be released under the GPL.

It just isn't possible to get best-in-class performance by calling
external functions. We need to be able to inline all code and fully
optimize it using all our existing and future optimizers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]