[PATCH] D143074: [LangRef] improve documentation of SNaN in the default FP environment

Jacob Lifshay via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 9 02:45:12 PST 2023


programmerjake added a comment.

In D143074#4114910 <https://reviews.llvm.org/D143074#4114910>, @RalfJung wrote:

>> Then, LLVM is broken on old MIPS. There's just no way it's okay to spuriously introduce sNaNs when the original program didn't contain sNaNs in the first place. It results in incorrect results, without the original user code breaking any assumptions.
>
> I think I am trying to understand why this is the case.

because, from what I understand, before IEEE 754 specified how to encode quietness for NaNs, MIPS (and PA-RISC) arbitrarily chose the opposite encoding to what IEEE 754-2008 specifies, so LLVM generating quiet NaNs following IEEE 754-2008 produces NaNs that are actually signalling NaNs for old MIPS. MIPS later added a mode bit allowing swapping its interpretation of signalling/quiet NaNs to fall in line with the IEEE 754-2008 spec -- new MIPS has that set to IEEE 754-2008 mode.

> So the alternative is to say that if any input is an sNaN, then it may be treated as if it was a qNaN and output NaN have arbitrary quietness, but if there are no sNaN inputs then all output NaN will be quiet.

That works, except for old MIPS, where LLVM's idea of what's quiet/signalling doesn't currently match.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143074/new/

https://reviews.llvm.org/D143074



More information about the llvm-commits mailing list