Try to clarify the semantics of fptrunc

* ``the value cannot fit within the destination type`` is ambiguous.
  It could mean overflow, underflow (not in the IEEE-754 sense) or a
  result that cannot be exactly represented and requires rounding or it
  could mean some combination of these. The semantics now state it means
  overflow **only**.

* Using "truncation" in the semantics is very misleading given that it
  doesn't necessarily truncate (i.e. round to zero). For example on
  x86_64 with SSE2 this is currently mapped to cvtsd2ss instruction
  who's rounding behaviour is dependent on the MXCSR register which
  is usually set to round to nearest even by default. The semantics
  now state that the rounding mode is undefined.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246792 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index b58fcf9b5ae190ff2ae14dea536047987288a8a1..fd41eb99bed392bb3f2b945e8c8f57338f91197a 100644 (file)
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -7524,10 +7524,12 @@ implies that ``fptrunc`` cannot be used to make a *no-op cast*.
 Semantics:
 """"""""""
 
-The '``fptrunc``' instruction truncates a ``value`` from a larger
+The '``fptrunc``' instruction casts a ``value`` from a larger
 :ref:`floating point <t_floating>` type to a smaller :ref:`floating
-point <t_floating>` type. If the value cannot fit within the
-destination type, ``ty2``, then the results are undefined.
+point <t_floating>` type. If the value cannot fit (i.e. overflows) within the
+destination type, ``ty2``, then the results are undefined. If the cast produces
+an inexact result, how rounding is performed (e.g. truncation, also known as
+round to zero) is undefined.
 
 Example:
 """"""""