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

[Sanjay Patel via Phabricator via llvm-commits]

spatel updated this revision to Diff 137428.
spatel marked 2 inline comments as done.
spatel added a comment.

Patch updated:
Improve/soften the wording - we make assumptions about the state of FP affairs.


https://reviews.llvm.org/D44216

Files:
  docs/LangRef.rst


Index: docs/LangRef.rst
===================================================================
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@ -3037,24 +3037,18 @@
 
 .. 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.
+By default, the optimizer does not model exceptions for floating-point 
+instructions (see constrained floating-point intrinsics for that 
+functionality), so we assume there are no side effects with 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 +6398,7 @@
 """"""""""
 
 The value produced is the floating-point sum of the two operands.
+This instruction is assumed not to 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 +6494,7 @@
 """"""""""
 
 The value produced is the floating-point difference of the two operands.
+This instruction is assumed not to 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 +6588,7 @@
 """"""""""
 
 The value produced is the floating-point product of the two operands.
+This instruction is assumed not to 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 +6721,7 @@
 """"""""""
 
 The value produced is the floating-point quotient of the two operands.
+This instruction is assumed not to 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 +6866,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 is assumed not to 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.137428.patch
Type: text/x-patch
Size: 3381 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180307/63845723/attachment.bin>