================ @@ -4045,18 +4045,56 @@ seq\_cst total orderings of other operations that are not marked Floating-Point Environment -------------------------- -The default LLVM floating-point environment assumes that traps are disabled and -status flags are not observable. Therefore, floating-point math operations do -not have side effects and may be speculated freely. Results assume the -round-to-nearest rounding mode, and subnormals are assumed to be preserved. - -Running LLVM code in an environment where these assumptions are not met -typically leads to undefined behavior. The ``strictfp`` and -:ref:`denormal_fpenv <denormal_fpenv>` attributes as well as -:ref:`Constrained Floating-Point Intrinsics <constrainedfp>` can be -used to weaken LLVM's assumptions and ensure defined behavior in -non-default floating-point environments; see their respective -documentation for details. +The execution of an operation on floating-point values is often a more complex +process than simply evaluating a function of its input arguments. First, it can +depend on various parameters like rounding mode, denormal behavior, trap masks +and so on. These are referenced to as "control modes" and are stored in +floating-point control registers. In addition, the operation may set status bits +in a status register. Floating-point environment is a collection of registers +that hold control modes and status bits. + +Interaction with the floating-point environment, including reading control +modes, writing status bits and trapping, is regarded as side effects. Depending +on how the side effects are treated, compilation occurs in one of two modes. + +In the ``strict mode``, all side effects produced by the floating-point +operations are taken into account. Modifications to the floating-point +environment are allowed only in this mode. + +In the ``unconstrained mode``, control modes are not modified and status bits +are not observed. This allows floating-point operations to be considered free +of side effects, which facilitates code optimizations. An important case of this +mode is the ``default mode``, in which the control modes have default values: +rounding mode is "round to nearest, ties to even", traps are disabled, and +subnormals are assumed to be preserved. + +The compilation mode is defined for an entire function and is specified by ---------------- spavloff wrote:
Formally, you are right, this is a user error. But the compiler silently produces wrong code and that does not look like correct behavior. It seems like we should prohibit inlining default-mode code into strictfp function. Moreover, not only inlining but any such call should be prohibited, which would result in a very inconvenient model. Probably it would be more practical to treat such default mode function as executed in dynamic environment. This topic, however, is beyond the scope of this patch. https://github.com/llvm/llvm-project/pull/188297 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
