On 05/15/2018 06:45 AM, Alex Bennée wrote:
>> +float64 float64_silence_nan(float64 a, float_status *status)
>> +{
>> + return float64_pack_raw(parts_silence_nan(float64_unpack_raw(a),
>> status));
>> +}
>> +
>
> Not that I'm objecting to the rationalisation but did you look at the
> code generated now we unpack NaNs? I guess NaN behaviour isn't the
> critical path for performance anyway....
Yes, I looked. It's about 5 instructions instead of 1.
But as you say, it's nowhere near critical path.
Ug. I've also just realized that the shift isn't correct though...
r~
