This is the mail archive of the gcc@gcc.gnu.org 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 Thu, Feb 9, 2012 at 4:20 PM, Geert Bosch <bosch@adacore.com> wrote:
>
> On Feb 9, 2012, at 08:46, Andrew Haley wrote:
>> n 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. ?As Richard says, it's
>>> certainly possible to do better in the context of SSE, but gcc doesn't
>>> know anything about the quality of math libraries present; it doesn't
>>> even take into account whether it's glibc or something else.
>>
>> Yeah. ?On x86_64 glibc, we should really get the sincos bg fixed. ?And
>> it really is a bug: cos() and sin() are correctly rounded but sincos()
>> isn't.
>
> It seems to be a persistent problem that we need to rely on a system-provided
> C library, instead of a math library that is installed with the compiler.
>
> For non-C languages, such as Ada, we need to meet specific accuracy
> requirements. However, we cannot distribute the latest glibc with the
> compiler for each target platform. In particular, it is common for
> users to install new compilers on (very) old OS versions. Even today,
> we cannot rely on the standard libm to be C99 compliant and provide
> a relative error of 2 epsilon (2-4 ulps) or better on ANY platform.
> So, the only way to have a conforming Ada implementation is to roll
> our own. It would be so much better if we could work on a common
> library that can be used by all languages.
>
> Given the fact that GCC already needs to know pretty much everything
> about these functions for optimizations and constant folding, and is
> in the best situation to choose specific implementations (-ffast-math
> or not, -frounding-math or not, -ftrapping-math or not, etc), specific
> optimizations (latency/throughput/vector optimized) ?and perform
> (partial) inlining, shouldn't we have a math library directly within GCC?

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

I'd definitely like to see this library also to host vectorized routines and
provide a myriad of entry-points.

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.

Thanks,
Richard.

> ?-Geert


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