[PATCH] D44216: [LangRef] make it clear that FP instructions do not have side effects

[Sanjay Patel via Phabricator via llvm-commits]

spatel created this revision.
spatel added reviewers: lattner, scanon, andrew.w.kaylor, nhaehnle, reames, efriedma, arsenm, RKSimon, majnemer, nlopes.
Herald added subscribers: wdng, mcrosier.

There may still be some ambiguity about the output with undef and special constants, but I think we have consensus that the LLVM FP opcodes operate in an environment with no trapping, so let's makes that explicit and fix the bogus example.

The existing text for the constrained intrinsics says:
"By default, LLVM optimization passes assume that the rounding mode is round-to-nearest and that floating point exceptions will not be monitored. Constrained FP intrinsics are used to support non-default rounding modes and accurately preserve exception behavior without compromising LLVM’s ability to optimize FP code when the default behavior is used."


https://reviews.llvm.org/D44216

Files:
  docs/LangRef.rst


Index: docs/LangRef.rst
===================================================================
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@ -3037,24 +3037,17 @@
 
 .. code-block:: llvm
 
-      %A = fdiv undef, %X
+      %A = fadd undef, %X
       %B = fdiv %X, undef
     Safe:
-      %A = undef
-    b: unreachable
+      %A = NaN
+      %B = NaN
 
-These examples show the crucial difference between an *undefined value*
-and *undefined behavior*. An undefined value (like '``undef``') is
-allowed to have an arbitrary bit-pattern. This means that the ``%A``
-operation can be constant folded to '``undef``', because the '``undef``'
-could be an SNaN, and ``fdiv`` is not (currently) defined on SNaN's.
-However, in the second example, we can make a more aggressive
-assumption: because the ``undef`` is allowed to be an arbitrary value,
-we are allowed to assume that it could be zero. Since a divide by zero
-has *undefined behavior*, we are allowed to assume that the operation
-does not execute at all. This allows us to delete the divide and all
-code after it. Because the undefined operation "can't happen", the
-optimizer can assume that it occurs in dead code.
+The LLVM floating-point opcodes assume default exception handling.
+There is no possibility of trapping with any of these instructions.
+Therefore, we return a NaN constant value in both cases. This is
+because if the variable operand is a NaN, then no other output is
+possible.
 
 .. code-block:: text
 
@@ -6404,6 +6397,7 @@
 """"""""""
 
 The value produced is the floating-point sum of the two operands.
+This instruction can not trap or have any other side effects.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:
@@ -6499,6 +6493,7 @@
 """"""""""
 
 The value produced is the floating-point difference of the two operands.
+This instruction can not trap or have any other side effects.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:
@@ -6592,6 +6587,7 @@
 """"""""""
 
 The value produced is the floating-point product of the two operands.
+This instruction can not trap or have any other side effects.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:
@@ -6724,6 +6720,7 @@
 """"""""""
 
 The value produced is the floating-point quotient of the two operands.
+This instruction can not trap or have any other side effects.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:
@@ -6868,6 +6865,7 @@
 This is the same output as a libm '``fmod``' function, but without any
 possibility of setting ``errno``. The remainder has the same sign as the 
 dividend.
+This instruction can not trap or have any other side effects.
 This instruction can also take any number of :ref:`fast-math
 flags <fastmath>`, which are optimization hints to enable otherwise
 unsafe floating-point optimizations:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D44216.137414.patch
Type: text/x-patch
Size: 3245 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180307/0663dd9c/attachment.bin>