Re: [PATCH] Implement range-op entry for sin/cos.

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-04-21 02:52, Jakub Jelinek wrote:
> On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
>> On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
>>> For bounds that aren't representable, one could get error bounds from
>>> libm-test-ulps data in glibc, although I reckon those won't be
>>> exhaustive.  From a quick peek at the sin/cos data, the arc target seems
>>> to be among the worst performers at about 7ulps, although if you include
>>> the complex routines we get close to 13 ulps.  The very worst
>>> imprecision among all math routines (that's gamma) is at 16 ulps for
>>> power in glibc tests, so maybe allowing about 25-30 ulps error in bounds
>>> might work across the board.
>>
>> I was thinking about this a bit more and it seems like limiting ranges to
>> targets that can generate sane results (i.e. error bounds within, say, 5-6
>> ulps) and for the rest, avoid emitting the ranges altogether. Emitting a bad
>> range for all architectures seems like a net worse solution again.
> 
> Well, at least for basic arithmetics when libm functions aren't involved,
> there is no point in disabling ranges altogether.

Oh yeah, I did mean only franges for math function call results.

> And, for libm functions, my plan was to introduce a target hook, which
> would have combined_fn argument to tell which function is queried,
> machine_mode to say which floating point format and perhaps a bool whether
> it is ulps for these basic math boundaries or results somewhere in between,
> and would return in unsigned int ulps, 0 for 0.5ulps precision.
> So, we could say for CASE_CFN_SIN: CASE_CFN_COS: in the glibc handler
> say that ulps is say 3 inside of the ranges and 0 on the boundaries if
> !flag_rounding_math and 6 and 2 with flag_rounding_math or whatever.
> And in the generic code don't assume anything if ulps is say 100 or more.
> The hooks would need to be a union of precision of supported versions of
> the library through the history, including say libmvec because function
> calls could be vectorized.
> And default could be that infinite precision.
> Back in November I've posted a proglet that can generate some ulps from
> random number testing, plus on glibc we could pick maximums from ulps files.
> And if needed, say powerpc*-linux could override the generic glibc
> version for some subset of functions and call default otherwise (say at
> least for __ibm128).

Ack, that sounds like a plan.

Thanks,
Sid