================
@@ -1847,19 +1847,50 @@ floating point semantic models: precise (the default),
strict, and fast.
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess
precision arithmetic.
+.. 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 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 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. For the case of multiplication overflow will
occur in
+ accordance with normal floating-point rules. This is the default value.
+ * ``promoted`` Implementation of complex division using algebraic formulas
at
+ higher precision. Overflow is handled. Non-finite values are handled in
some
+ cases. If the target does not have native support for a higher precision
+ data type, an implementation for the complex operation will be used to
provide
+ improved guards against intermediate overflow, but overflow and underflow
may
+ still occur in some cases. NaN and infinite values are not handled.
----------------
andykaylor wrote:
The intention here was that if the target doesn't support a higher precision
type, we will do what we would have done with "improved". Some targets don't
even support a 64-bit floating-point type, so the way we apply this needs to be
generalized. Should we issue a warning if the user specifies "promoted" but we
can't promote?
Zahira and I talked about this offline, and my suggestion was that if
LongDoubleSize is greater than DoubleSize, we can promote double to long
double, but if it isn't we will use the Smith algorithm (i.e. "improved").
Windows on x86-64 is the really ugly case here, because the target hardware
supports an 80-bit floating-point type, but by default the operating system
configures the x87 layer to perform calculations as if it were a 64-bit type.
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
