On 10 February 2012 10:42, Andrew Haley <a...@redhat.com> wrote: > On 02/10/2012 10:07 AM, Richard Guenther wrote: >> >> The issue with libm in glibc here is that Drepper absolutely does >> not want new ABIs in libm - he believes that for example vectorized >> routines do not belong there (nor the SSE calling-convention variants >> for i686 I tried to push once). > > That's a good reason why we can't do this in glibc. I accept > the point; it'll have to be GNU libm. > > Andrew.
I think a starting point would be at least documenting correctly the accuracy of the current libm, because what is currently in the documents is obviously wrong. It certainly does not document that sin() is currently more accurate than sinl() on x86_64 platforms, even with -O0. I think the documentation should be along the lines of for Function name: sin(x) -pi/2 < x < pi/2, accuracy is +-N pi/2 < x < large number, accuracy is +-N large number < x < max_float, accuracy is +-N If a performance figure could also be added, so much the better. We could then know that implementation 1 is quicker than implementation 2 and the programmer can do the trade offs. And have the figures repeated for various options such as -ffast-math etc, and also repeated for different CPUs etc. Once we have the documentation, we can then ensure, using automated testing, that the libm actually performs as designed.
