[libre-riscv-dev] [isa-dev] FP reciprocal sqrt extension proposal

[Jacob Lifshay]

On Thu, Jul 11, 2019, 13:42 Guy Lemieux <glemieux at vectorblox.com> wrote:

> 1/sqrt(a) is a single-operand instruction.
>
> might there be more performance value in making it dual-operand to make
> better use of available read ports, eg:
>
> a/sqrt(b)
>   or
> 1/sqrt(a+b)
>
> both are common forms of usage. i suppose these could be formed by
> chaining, but if that’s the case there’s little need for rsqrt if you have
> both div and sqrt.
>
the reason for not just chaining two instructions is that sqrt followed by
div gives different results due to rounding twice. div followed by sqrt
gives different results due to rounding twice, returning NaN instead of
-Inf for -0 inputs, and very small inputs overflow to +Inf where rsqrt
won't ever overflow or underflow.

1/sqrt(a+b) additionally gives different results for special cases,
assuming the addition is defined the same as fadd, since the sign of the
result is different for different rounding modes when adding +0 and -0,
whereas (if I recall correctly) IEEE 754-2008 defines rsqrt(+0) to give
+Inf and rsqrt(-0) to give -Inf for all rounding modes.

I think having a frsqrt instruction that doesn't need an additional input
will be useful since the compiler doesn't have to load the constant 1 (for
a/sqrt(b)) or +0 or -0 (for 1/sqrt(a+b)).

Additionally, frsqrt is a commonly implemented operation, so already
working and verified single-input frsqrt HW is readily available, whereas
the modified versions that have 2 inputs aren't as likely to be available,
and it would quite complex to implement and verify a new FP unit, greatly
restricting who can implement the Zfrsqrt extension.

I have no problems modifying the encoding to permit 2-input frsqrt, I just
think that should be an additional extension on top of Zfrsqrt.


Jacob