[Mesa-dev] [PATCH] gallivm: unify sin and cos implementation

[Roland Scheidegger]

Am 21.08.2013 01:28, schrieb Roland Mainz:
> On Wed, Aug 21, 2013 at 1:12 AM,  <sroland at vmware.com> wrote:
>> From: Roland Scheidegger <sroland at vmware.com>
>>
>> The (complicated!) math is all identical, there's just minimal differences how
>> sign bit is calculated plus there's an additional subtraction for the argument
>> going into the polynomial for cos.
>> The logic stays 100% the same (with a small exception, sign bit calculation for
>> sin is minimally simplified, applying sign mask after xoring the arguments
>> instead of applying it to each argument).
>> ---
>>  src/gallium/auxiliary/gallivm/lp_bld_arit.c |  300 ++++-----------------------
>>  1 file changed, 46 insertions(+), 254 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> index f7daabc..03e0aa6 100644
> [snip]
>> -   /* If a is -inf, inf or NaN then return NaN */
> [snip]
> 
> Note that the comment about NaN in the old code is not 100% correct
> (ksh93 and ISO C behave the same in this case since POSIX sh $((...))
> uses ISO C expressions):
> -- snip --
> $ ksh93 -c 'print -- $(( sin(-nan) ))'
> -nan
> $ ksh93 -c 'print -- $(( sin(+nan) ))'
> nan
> -- snip --
> 
> Can you check whether the new code supports -nan correctly, please
> (-nan is used by scientific software... we learned that the hard way
> when we had to fix this in ksh93 for Sun) ?
> 

This code is built to adhere to graphics apis, usually d3d10 (because it
tends to be more strict than opengl/glsl).
As such there's no rules (I think) as far as propagating "the right nan"
concerns, and there's no distinction really between negative/positive
QNaNs/SNaNs. The is_finite will catch all kind of nans (plus infs,
obviously), but the output will always be the same NaN in this case,
sign bits etc. will be lost (though IIRC sign bit, while possible with
nan's, doesn't really have much meaning anyway).

Roland