[all-commits] [llvm/llvm-project] d68881: [LangRef] Specify NaN behavior more precisely (#66...

[Ralf Jung via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d688816627763c04ccf67b8522596f95f2400ca6
      https://github.com/llvm/llvm-project/commit/d688816627763c04ccf67b8522596f95f2400ca6
  Author: Ralf Jung <post at ralfj.de>
  Date:   2023-10-04 (Wed, 04 Oct 2023)

  Changed paths:
    M llvm/docs/LangRef.rst

  Log Message:
  -----------
  [LangRef] Specify NaN behavior more precisely (#66579)

The current docs don't say anything about the possible set of values
returned by a NaN-producing operation. However, there are some coding
patterns where such guarantees are strongly desired, such as NaN boxing
(as used e.g. in the Spidermonkey JS engine). And in fact the set of
possible payloads that can be observed today when compiling code via
LLVM is fairly limited (based on what optimizations and backends and
hardware currently do) -- but without a documented guarantee, languages
compiling to LLVM cannot really rely on this.

There was a long discussion about the exact shape that the guarantees
should take [on Discourse](https://discourse.llvm.org/t/stronger-floating-point-nan-guarantees/72165).
This PR transcribes what I perceived as the consensus, plus some further
clarifications: "unless specified otherwise", returned NaNs have a
non-deterministic sign, and the payload is generally either the
preferred (all-zero) payload or propagates the payload of one of the
inputs.