[LangRef] Normalize IEEE 754 spelling

[nikic]

We currently use three spellings, "IEEE754", "IEEE-754" and "IEEE 754". Normalize to the latter.

Per @jcranmer-intel this is the preferred form.

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: Nikita Popov (nikic)

Changes

We currently use three spellings, "IEEE754", "IEEE-754" and "IEEE 754". Normalize to the latter.

Per @jcranmer-intel this is the preferred form.

---

Full diff: https://github.com/llvm/llvm-project/pull/174721.diff

1 Files Affected:

• (modified) llvm/docs/LangRef.rst (+31-31)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 041a526b6729f..e626ac824dee7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -4034,8 +4034,8 @@ are not "floating-point math operations": ``fneg``, ``llvm.fabs``, and
 representation and never change anything except possibly for the sign bit.
 
 Floating-point math operations that return a NaN are an exception from the
-general principle that LLVM implements IEEE-754 semantics. Unless specified
-otherwise, the following rules apply whenever the IEEE-754 semantics say that a
+general principle that LLVM implements IEEE 754 semantics. Unless specified
+otherwise, the following rules apply whenever the IEEE 754 semantics say that a
 NaN value is returned: the result has a non-deterministic sign; the quiet bit
 and payload are non-deterministically chosen from the following set of options:
 
@@ -4089,13 +4089,13 @@ Floating-Point Semantics
 ------------------------
 
 This section defines the semantics for core floating-point operations on types
-that use a format specified by IEEE-754. These types are: ``half``, ``float``,
+that use a format specified by IEEE 754. These types are: ``half``, ``float``,
 ``double``, and ``fp128``, which correspond to the binary16, binary32, binary64,
 and binary128 formats, respectively. The "core" operations are those defined in
-section 5 of IEEE-754, which all have corresponding LLVM operations.
+section 5 of IEEE 754, which all have corresponding LLVM operations.
 
 The value returned by those operations matches that of the corresponding
-IEEE-754 operation executed in the :ref:`default LLVM floating-point environment
+IEEE 754 operation executed in the :ref:`default LLVM floating-point environment
 <floatenv>`, except that the behavior of NaN results is instead :ref:`as
 specified here <floatnan>`. In particular, such a floating-point instruction
 returning a non-NaN value is guaranteed to always return the same bit-identical
@@ -4438,7 +4438,7 @@ Floating-Point Types
      - Description
 
    * - ``half``
-     - 16-bit floating-point value (IEEE-754 binary16)
+     - 16-bit floating-point value (IEEE 754 binary16)
 
    * - ``bfloat``
      - 16-bit "brain" floating-point value (7-bit significand).  Provides the
@@ -4447,13 +4447,13 @@ Floating-Point Types
        extensions and Arm's ARMv8.6-A extensions, among others.
 
    * - ``float``
-     - 32-bit floating-point value (IEEE-754 binary32)
+     - 32-bit floating-point value (IEEE 754 binary32)
 
    * - ``double``
-     - 64-bit floating-point value (IEEE-754 binary64)
+     - 64-bit floating-point value (IEEE 754 binary64)
 
    * - ``fp128``
-     - 128-bit floating-point value (IEEE-754 binary128)
+     - 128-bit floating-point value (IEEE 754 binary128)
 
    * - ``x86_fp80``
      -  80-bit floating-point value (X87)
@@ -4887,7 +4887,7 @@ and disassembly do not cause any bits to change in the constants.
 
 When using the hexadecimal form, constants of types bfloat, half, float, and
 double are represented using the 16-digit form shown above (which matches the
-IEEE754 representation for double); bfloat, half and float values must, however,
+IEEE 754 representation for double); bfloat, half and float values must, however,
 be exactly representable as bfloat, IEEE 754 half, and IEEE 754 single
 precision respectively. Hexadecimal format is always used for long double, and
 there are three forms of long double. The 80-bit format used by x86 is
@@ -16263,7 +16263,7 @@ Semantics:
 """"""""""
 
 Return the same value as a corresponding libm '``sqrt``' function but without
-trapping or setting ``errno``. For types specified by IEEE-754, the result
+trapping or setting ``errno``. For types specified by IEEE 754, the result
 matches a conforming libm implementation.
 
 When specified with the fast-math-flag 'afn', the result may be approximated
@@ -17258,7 +17258,7 @@ The arguments and return value are floating-point numbers of the same type.
 Semantics:
 """"""""""
 
-Return the same value as the IEEE-754 fusedMultiplyAdd operation. This
+Return the same value as the IEEE 754 fusedMultiplyAdd operation. This
 is assumed to not trap or set ``errno``.
 
 When specified with the fast-math-flag 'afn', the result may be approximated
@@ -17313,7 +17313,7 @@ are perfectly preserved.
 Standard:
 """""""""
 
-IEEE754 and ISO C define some min/max operations, and they have some differences
+IEEE 754 and ISO C define some min/max operations, and they have some differences
 on working with qNaN/sNaN and +0.0/-0.0. Here is the list:
 
 .. list-table::
@@ -17324,7 +17324,7 @@ on working with qNaN/sNaN and +0.0/-0.0. Here is the list:
      - fmininum/fmaximum
      - fminimum_num/fmaximum_num
 
-   * - ``IEEE754``
+   * - ``IEEE 754``
      - minNum/maxNum (2008)
      - minimum/maximum (2019)
      - minimumNumber/maximumNumber (2019)
@@ -17430,7 +17430,7 @@ type.
 
 Semantics:
 """"""""""
-Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+Follows the semantics of minNum in IEEE 754-2008, except that -0.0 < +0.0 for the purposes
 of this intrinsic. As for signaling NaNs, per the minNum semantics, if either operand is sNaN,
 the result is qNaN. This matches the recommended behavior for the libm
 function ``fmin``, although not all implementations have implemented these recommended behaviors.
@@ -17440,11 +17440,11 @@ NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consis
 so arithmetic feeding into a minnum can produce inconsistent results. For example,
 ``minnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
 
-IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
+IEEE 754-2008 defines minNum, and it was removed in IEEE 754-2019. As the replacement, IEEE 754-2019
 defines :ref:`minimumNumber <i_minimumnum>`.
 
 If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
-and IEEE-754-2008: the result of ``minnum(-0.0, +0.0)`` may be either -0.0 or +0.0.
+and IEEE 754-2008: the result of ``minnum(-0.0, +0.0)`` may be either -0.0 or +0.0.
 
 Some architectures, such as ARMv8 (FMINNM), LoongArch (fmin), MIPSr6 (min.fmt), PowerPC/VSX (xsmindp),
 have instructions that match these semantics exactly; thus it is quite simple for these architectures.
@@ -17490,7 +17490,7 @@ type.
 
 Semantics:
 """"""""""
-Follows the semantics of maxNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+Follows the semantics of maxNum in IEEE 754-2008, except that -0.0 < +0.0 for the purposes
 of this intrinsic. As for signaling NaNs, per the maxNum semantics, if either operand is sNaN,
 the result is qNaN. This matches the recommended behavior for the libm
 function ``fmax``, although not all implementations have implemented these recommended behaviors.
@@ -17500,11 +17500,11 @@ NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consis
 so arithmetic feeding into a maxnum can produce inconsistent results. For example,
 ``maxnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
 
-IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
+IEEE 754-2008 defines maxNum, and it was removed in IEEE 754-2019. As the replacement, IEEE 754-2019
 defines :ref:`maximumNumber <i_maximumnum>`.
 
 If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
-and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
+and IEEE 754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
 
 Some architectures, such as ARMv8 (FMAXNM), LoongArch (fmax), MIPSr6 (max.fmt), PowerPC/VSX (xsmaxdp),
 have instructions that match these semantics exactly; thus it is quite simple for these architectures.
@@ -17637,7 +17637,7 @@ return the number.  Otherwise returns the lesser of the two
 arguments. -0.0 is considered to be less than +0.0 for this intrinsic.
 
 Note that these are the semantics of minimumNumber specified in
-IEEE-754-2019 with the usual :ref:`signaling NaN <floatnan>` exception.
+IEEE 754-2019 with the usual :ref:`signaling NaN <floatnan>` exception.
 
 It has some differences with '``llvm.minnum.*``':
 1)'``llvm.minnum.*``' will return qNaN if either operand is sNaN.
@@ -17686,7 +17686,7 @@ greater of the two arguments. -0.0 is considered to be less than +0.0
 for this intrinsic.
 
 Note that these are the semantics of maximumNumber specified in
-IEEE-754-2019  with the usual :ref:`signaling NaN <floatnan>` exception.
+IEEE 754-2019  with the usual :ref:`signaling NaN <floatnan>` exception.
 
 It has some differences with '``llvm.maxnum.*``':
 1)'``llvm.maxnum.*``' will return qNaN if either operand is sNaN.
@@ -18004,7 +18004,7 @@ The argument and return value are floating-point numbers of the same type.
 Semantics:
 """"""""""
 
-This function implements IEEE-754 operation ``roundToIntegralTiesToEven``. It
+This function implements IEEE 754 operation ``roundToIntegralTiesToEven``. It
 also behaves in the same way as C standard function ``roundeven``, including
 that it disregards rounding mode and does not raise floating point exceptions.
 
@@ -19754,7 +19754,7 @@ Overview:
 The '``llvm.canonicalize.*``' intrinsic returns the platform-specific canonical
 encoding of a floating-point number. This canonicalization is useful for
 implementing certain numeric primitives such as frexp. The canonical encoding is
-defined by IEEE-754-2008 to be:
+defined by IEEE 754-2008 to be:
 
 ::
 
@@ -19762,7 +19762,7 @@ defined by IEEE-754-2008 to be:
       representation in a format. Applied to declets, significands of finite
       numbers, infinities, and NaNs, especially in decimal formats.
 
-This operation can also be considered equivalent to the IEEE-754-2008
+This operation can also be considered equivalent to the IEEE 754-2008
 conversion of a floating-point value to the same format. NaNs are handled
 according to section 6.2.
 
@@ -19776,7 +19776,7 @@ Examples of non-canonical encodings:
   These are treated as non-canonical encodings of zero and will be flushed to
   a zero of the same sign by this operation.
 
-Note that per IEEE-754-2008 6.2, systems that support signaling NaNs with
+Note that per IEEE 754-2008 6.2, systems that support signaling NaNs with
 default exception handling must signal an invalid exception, and produce a
 quiet NaN result.
 
@@ -22900,7 +22900,7 @@ This is an overloaded intrinsic.
 Overview:
 """""""""
 
-Predicated floating-point IEEE-754-2008 minNum of two vectors of floating-point values.
+Predicated floating-point IEEE 754-2008 minNum of two vectors of floating-point values.
 
 
 Arguments:
@@ -22949,7 +22949,7 @@ This is an overloaded intrinsic.
 Overview:
 """""""""
 
-Predicated floating-point IEEE-754-2008 maxNum of two vectors of floating-point values.
+Predicated floating-point IEEE 754-2008 maxNum of two vectors of floating-point values.
 
 
 Arguments:
@@ -29194,7 +29194,7 @@ The third argument specifies the exception behavior as described above.
 Semantics:
 """"""""""
 
-This function follows the IEEE-754-2008 semantics for maxNum.
+This function follows the IEEE 754-2008 semantics for maxNum.
 
 
 '``llvm.experimental.constrained.minnum``' Intrinsic
@@ -29226,7 +29226,7 @@ The third argument specifies the exception behavior as described above.
 Semantics:
 """"""""""
 
-This function follows the IEEE-754-2008 semantics for minNum.
+This function follows the IEEE 754-2008 semantics for minNum.
 
 
 '``llvm.experimental.constrained.maximum``' Intrinsic
@@ -29423,7 +29423,7 @@ The second argument specifies the exception behavior as described above.
 Semantics:
 """"""""""
 
-This function implements IEEE-754 operation ``roundToIntegralTiesToEven``. It
+This function implements IEEE 754 operation ``roundToIntegralTiesToEven``. It
 also behaves in the same way as C standard function ``roundeven`` and can signal
 the invalid operation exception for a SNAN argument.
 

[rengolin]

I confirm, this is the most common spelling I have seen on official documents. Regardless, having one spelling is better than three any day.

[bd1976bris]

This makes this doc consistent. I notice there is a mixture of spellings throughout the code though. Perhaps using the IEEE754 spelling here would be best as that can be used consistently everywhere?

[bd1976bris]

This makes this doc consistent. I notice there is a mixture of spellings throughout the code though. Perhaps using the IEEE754 spelling here would be best as that can be used consistently everywhere?

I didn't mean to block this review. This was meant to be a helpful take-it-or-leave-it type suggestion. I'm happy with the patch as it is.