Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Michael Matz via Gcc-patches
Hello, On Thu, 27 Apr 2023, Jakub Jelinek wrote: > The first really large error I see is for sinl with > x/2gx > 0x748160ed90d9425b0xefd8b811d6293294 > i.e. > 1.5926552660973502228303666578452949e+253 > with most significant double being > 1.5926552660973502e+253 > and low double >

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Jakub Jelinek via Gcc-patches
On Thu, Apr 27, 2023 at 10:59:47AM +0200, Jakub Jelinek via Gcc-patches wrote: > I guess I'll need to look at the IBM double double sinl/cosl results, > either it is some bug in my tester or the libm functions are useless. > But appart from the MODE_COMPOSITE_P cases, I think all the numbers are >

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Richard Biener via Gcc-patches
On Thu, 27 Apr 2023, Jakub Jelinek wrote: > On Thu, Apr 27, 2023 at 07:18:52AM +, Richard Biener wrote: > > Humm. Is it worth the trouble? I think if we make use of this it needs > > I think so. Without that, frange is half blind, using at least most common > libm functions in floating

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Jakub Jelinek via Gcc-patches
On Thu, Apr 27, 2023 at 07:18:52AM +, Richard Biener wrote: > Humm. Is it worth the trouble? I think if we make use of this it needs I think so. Without that, frange is half blind, using at least most common libm functions in floating point code is extremely common and without knowing

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Jakub Jelinek via Gcc-patches
On Wed, Apr 26, 2023 at 04:10:32PM +, Michael Matz wrote: > On Wed, 26 Apr 2023, Jakub Jelinek via Gcc-patches wrote: > > > For glibc I've gathered data from: > > 4) using attached ulp-tester.c (how to invoke in file comment; tested > >both x86_64, ppc64, ppc64le 50M pseudo-random values

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-27 Thread Richard Biener via Gcc-patches
On Wed, 26 Apr 2023, Jakub Jelinek wrote: > Hi! > > As has been discussed before, the following patch adds target hook > for math library function maximum errors measured in ulps. > The default is to return ~0U which is a magic maximum value which means > nothing is known about precision of the

Re: [PATCH] Add targetm.libm_function_max_error

2023-04-26 Thread Michael Matz via Gcc-patches
Hello, On Wed, 26 Apr 2023, Jakub Jelinek via Gcc-patches wrote: > For glibc I've gathered data from: > 4) using attached ulp-tester.c (how to invoke in file comment; tested >both x86_64, ppc64, ppc64le 50M pseudo-random values in all 4 rounding >modes, plus on x86_64 float/double

[PATCH] Add targetm.libm_function_max_error

2023-04-26 Thread Jakub Jelinek via Gcc-patches
Hi! As has been discussed before, the following patch adds target hook for math library function maximum errors measured in ulps. The default is to return ~0U which is a magic maximum value which means nothing is known about precision of the match function. The first argument is unsigned int