[llvm] specify NaN behavior more precisely (PR #66579)

Ralf Jung via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 21 00:58:24 PDT 2023


RalfJung wrote:

So for fpext/fptruncate, what does this mean? Should we add something like this?

`fpext`:
> If ``value`` is a NaN, then the result will be a NaN with the same sign, with the quiet/signaling bit either preserved or reset to ``1``, and with the payload extended by extension with
least-significant zeroes.

`fptruncate`:
> If ``value`` is a NaN, then the result will be a NaN with the same sign, with the quiet/signaling bit either preserved or reset to ``1``, and with the payload truncated by removing the
least significant bits.

Or is that not correct and the payload may be reset to the preferred payload as well?
Are we sufficiently sure that this is correct for all hardware? It seems to be stricter than what IEEE mandates. The alternative would be to say that the payload is arbitrary.

https://github.com/llvm/llvm-project/pull/66579


More information about the llvm-commits mailing list