>> + float_status *s = &env->vfp.standard_fp_status;
>> + float64 one = int64_to_float64(1, s);
> You don't need to create a variable for this, float64_one
> will do what you want.
OK
>> + /* q = (int)(a * 512.0) */
>> + float64 x512 = int64_to_float64(512, s);
>> + float64 q = float64_mul(x512, a, s);
>> + int64_t q_int = float64_to_int64_round_to_zero(q, s);
>> +
>> + /* r = 1.0 / (((double)q + 0.5) / 512.0) */
>> + q = int64_to_float64(q_int, s);
>> + float64 half = float64_div(one, int64_to_float64(2, s), s);
> ...and a runtime division just to get a constant 0.5?
> Better to just make_float64() on the appropriate bit
> pattern, I think.
It makes sense.
Then, what about using the right bit patterns for 512 and 256?
Actually, for these last two, I mimicked recps and rsqrts which build constants
2 and 3. I could add another patch to address this point.
>> + if (float32_is_any_nan(a)) {
>> + return float32_default_nan;
> This won't set InvalidOp if the input is a signalling NaN.
Thanks for the notice, I have no means of testing those cases.
Christophe.
