future possibility: deterministic sign for SNaN

Author: RalfJung

text/0000-float-semantics.md

@@ -284,3 +284,5 @@ In Rust itself, questions around float semantics have been discussed for a long
 - In the future, we could attempt to obtain a deterministic specification for the sign bit produced by `0.0 / 0.0` (and in general, by operations that create a NaN without there being a NaN input). However, behavior here differs between x86 and ARM: x86 produces a negative NaN and ARM a positive NaN. LLVM always constant-folds this to a positive NaN -- so doing anything like this is blocked on making the LLVM float const-folder more target-aware.
 - For some usecases it can be valuable to run Rust code with a different floating-point environment. However there are major open questions around how to achieve this: without assuming that the floating-point environment is in its default state, compile-time folding of floating-point operations becomes hard to impossible. Any proposal for allowing alternative floating-point operations has to explain how it can avoid penalizing optimizations of code that just wants to use the default settings. [Here's what LLVM offers on that front](https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics). C has `#pragma STD FENV_ACCESS` and `#pragma STDC FENV_ROUND` for that; once clang supports those directives, we should determine if we are happy with their semantics and consider also exposing them in Rust.
 - To support fast-math transformations, separate fast-path intrinsics / types could be introduced in the future (also see [this issue](https://github.com/rust-lang/rust/issues/21690)).
+- There might be a way to specify floating-point operations such that if they return a signaling NaN, then the sign is deterministic.
+  However, doing so would require (a) coming up with a suitable specification and then (b) convincing LLVM to adopt that specification.