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 14, 2012, at 08:22, Vincent Lefevre wrote:
> Please do not use the term binary80, as it is confusing (and
> there is a difference between this format and the formats of
> the IEEE binary{k} class concerning the implicit bit).
Yes, I first wrote extended precision, though that really is
a general term that could denote many different formats.
I'll write Intel extended precision in the future. :)
> IEEE 754 recommends correct rounding (which should not be much slower
> than a function accurate to a few ulp's, in average) in the full range.
> I think this should be the default. The best compromise between speed
> and accuracy depends on the application, and the compiler can't guess
> anyway.

While I'm sympathetic to that sentiment, the big issue is that we
don't have a correctly rounded math library supporting all formats
and suitable for all targets. We can't default to something we
don't have.

Right now we don't have a library either that conforms to C99
and meets the far more relaxed accuracy criteria of OpenCL and

However, the glibc math library comes very close, and we can
surely fix any remaining issues there may be. So, if we can
use that as base, or as "fallback" library, we suddenly
achieve some minimal accuracy guarantees across a wide
range of platforms. If we can get this library with
GPL+exception, we can even generate optimized variants
and use a static library with LTO byte code allowing for
inlining etc.

Then we can collect/write code that improves on this libm.


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