mention fast-math intrinsics as a future possibility

Author: RalfJung

text/0000-float-semantics.md

@@ -203,7 +203,7 @@ We could provide weaker guarantees to allow such transformations.
 However, there is no way to bound the effect of such transformations on program behavior: they lead to different outcome observable via `to_bits` and even via pure float operations, which can balloon into arbitrary changes in behavior.
 There is also no "monotonicity of precision": while e.g. an FMA instead of mul-then-add will lead to a higher-precision result for this particular operation, this can in principle lead to a lower-precision result in later computations (e.g., `x*x - x*x` can produce non-zero results after being transformed to `x.mul_add(x, -x*x)`).
 
-Given all these caveats, it seems preerrable to have explicit opt-in for such semantics-alterating transformations, e.g. via "fast" floating point operation intrinsics that don't provide strict IEEE semantics (and a type that uses those intrinsics for its operations).
+Given all these caveats, it seems preferable to have explicit opt-in for such semantics-alternating transformations, e.g. via "fast" floating point operation intrinsics that don't provide strict IEEE semantics (and a type that uses those intrinsics for its operations).
 
 ## Alternative options for `const` semantics
 
@@ -280,3 +280,4 @@ The sign bit is left unspecified, i.e., there are two canonical NaNs (and both a
 - Currently this RFC only talks about scalar `f32`/`f64` operations. What about their (unstable) SIMD equivalents in `std::simd`? Presumably we want all the same rules to apply. The main problem here seems to be 32bit ARM, whose NEON SIMD operations do not follow the usual semantics (they always flush to zero). We can either document this as an errata for that target, or avoid using NEON for `std::simd`.
 - 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)).