================
@@ -1847,19 +1847,33 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
-.. option:: -fcx-limited-range:
-
- This option enables the naive mathematical formulas for complex division and
- multiplication with no NaN checking of results. The default is
- ``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math``
- option.
-
-.. option:: -fcx-fortran-rules:
-
- This option enables the naive mathematical formulas for complex
- multiplication and enables application of Smith's algorithm for complex
- division. See SMITH, R. L. Algorithm 116: Complex division. Commun.
- ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``.
+.. option:: -fcomplex-arithmetic=<value>:
+
+ This option specifies the implementation for complex multiplication and
division.
+
+ Valid values are: ``basic``, ``improved``, ``full`` and ``promoted``.
+
+ * ``basic`` Implementation of complex division and multiplication using
+ algebraic formulas at source precision. No special handling to avoid
+ overflow. NaN and infinite and values are not handled.
+ * ``improved`` Implementation of complex division using the Smith algorithm
at
+ source precision. Smith's algorithm for complex division.
+ See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962).
+ This value offers improved handling for overflow in intermediate
calculations,
+ but overflow may occur. NaN and infinite and values are not handled in
some
+ cases.
+ * ``full`` Implementation of complex division and multiplication using a
+ call to runtime library functions (generally the case, but the BE might
+ sometimes replace the library call if it knows enough about the potential
+ range of the inputs). Overflow and non-finite values are handled by the
+ library implementation.
----------------
andykaylor wrote:
In the case of multiplication, the library call is only needed to handle
non-finite values. Overflow occurs in accordance with normal floating-point
rules. That is, even if we promoted to a higher precision type, the same
overflow would occur when we truncate back to the source type. This isn't true
for division because of the nature of the intermediate calculations.
https://github.com/llvm/llvm-project/pull/81514
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
