[MLIR] Fix `ComplexToStandard` lowering of `complex::MulOp` (#119591)

A complex multiplication should lower simply to the familiar 4 real
multiplications, 1 real addition, 1 real subtraction. No spe

[MLIR] Fix `ComplexToStandard` lowering of `complex::MulOp` (#119591)

A complex multiplication should lower simply to the familiar 4 real
multiplications, 1 real addition, 1 real subtraction. No special-casing
of infinite or NaN values should be made, instead the complex numbers
should be thought as just vectors of two reals, naturally bottoming out
on the reals' semantics, IEEE754 or otherwise. That is what nearly
everybody else is doing ("nearly" because at the end of this PR
description we pinpoint the actual source of this in C99 `_Complex`),
and this pattern, by trying to do something different, was generating
much larger code, which was much slower and a departure from the
naturally expected floating-point behavior.

This code had originally been introduced in
https://reviews.llvm.org/D105270, which stated this rationale:
> The lowering handles special cases with NaN or infinity like C++.

I don't think that the C++ standard is a particularly important thing to
follow in this instance. What matters more is what people actually do in
practice with complex numbers, which rarely involves the C++
`std::complex` library type.

But out of curiosity, I checked, and the above statement seems
incorrect. The [current C++
standard](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4928.pdf)
library specification for `std::complex` does not say anything about the
implementation of complex multiplication: paragraph `[complex.ops]`
falls back on `[complex.member.ops]` which says:
> Effects: Multiplies the complex value rhs by the complex value *this
and stores the product in *this.

I also checked cppreference which often has useful information in case
something changed in a c++ language revision, but likewise, nothing at
all there:
https://en.cppreference.com/w/cpp/numeric/complex/operator_arith3

Finally, I checked in Compiler Explorer what Clang 19 currently
generates:
https://godbolt.org/z/oY7Ks4j95
That is just the familiar 4 multiplications.... and then there is some
weird check (`fcmp`) and conditionally a call to an external `__mulsc3`.
Googled that, found this StackOverflow answer:
https://stackoverflow.com/a/49438578

Summary: this is not about C++ (this post confirms my reading of the C++
standard not mandating anything about this). This is about C, and it
just happens that this C++ standard library implementation bottoms out
on code shared with the C `_Complex` implementation.

Another nuance missing in that SO answer: this is actually
[implementation-defined
behavior](https://en.cppreference.com/w/c/preprocessor/impl). There are
two modes, controlled by
```c
#pragma STDC CX_LIMITED_RANGE {ON,OFF,DEFAULT}
```
It is implementation-defined which is the default. Clang defaults to
OFF, but that's just Clang. In that mode, the check is required:

https://en.cppreference.com/w/c/language/arithmetic_types#Complex_floating_types
And the specific point in the [C99
standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
is: `G.5.1 Multiplicative operators`.

But set it to ON and the check is gone:
https://godbolt.org/z/aG8fnbYoP

Summary: the argument has moved from C++ to C --- and even there, to
implementation-defined behavior with a standard opt-out mechanism.

Like with C++, I maintain that the C standard is not a particularly
meaningful thing for MLIR to follow here, because people doing business
with complex numbers tend to lower them to real numbers themselves, or
have their own specialized complex types, either way not relying on
C99's `_Complex` type --- and the very poor performance of the
`CX_LIMITED_RANGE OFF` behavior (default in Clang) is certainly a key
reason why people who care prefer to stay away from `_Complex` and
`std::complex`.

A good example that's relevant to MLIR's space is CUDA's `cuComplex`
type (used in the cuBLAS CGEMM interface). Here is its multiplication
function. The comment about competitiveness is interesting: it's not a
quirk of this particular function, it's the spirit underpinning
numerical code that matters.

https://github.com/tpn/cuda-samples/blob/1bf5cd15c51ce80fc9b387c0ff89a9f535b42bf5/v8.0/include/cuComplex.h#L106-L120
```c

/* This implementation could suffer from intermediate overflow even though
* the final result would be in range. However, various implementations do
* not guard against this (presumably to avoid losing performance), so we
* don't do it either to stay competitive.
*/
__host__ __device__ static __inline__ cuFloatComplex cuCmulf (cuFloatComplex x,
cuFloatComplex y)
{
cuFloatComplex prod;
prod = make_cuFloatComplex ((cuCrealf(x) * cuCrealf(y)) -
(cuCimagf(x) * cuCimagf(y)),
(cuCrealf(x) * cuCimagf(y)) +
(cuCimagf(x) * cuCrealf(y)));
return prod;
}
```

Another instance in CUTLASS:
https://github.com/NVIDIA/cutlass/blob/main/include/cutlass/complex.h#L231-L236

Signed-off-by: Benoit Jacob <jacob.benoit.1@gmail.com>

show more ...

[mlir] Fix -Wsign-compare in ComplexToStandard.cpp (NFC)

/llvm-project/mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:529:21:
error: comparison of integers of different signs: 'int' an

[mlir] Fix -Wsign-compare in ComplexToStandard.cpp (NFC)

/llvm-project/mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:529:21:
error: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]
529 | for (int i = 1; i < coefficients.size(); ++i) {
| ~ ^ ~~~~~~~~~~~~~~~~~~~
1 error generated.

show more ...

[mlir][complex] Add a numerically-stable lowering for complex.expm1. (#115082)

The current conversion to Standard in the MLIR repo is not stable for
small imag(arg).

Fix complex abs with nnan/ninf. (#95080)

The current logic tests for inf/inf and 0/0 inputs using a NaN check.
This doesn't work with all fastmath flags. With nnan and ninf, we can
just check for

Fix complex abs with nnan/ninf. (#95080)

The current logic tests for inf/inf and 0/0 inputs using a NaN check.
This doesn't work with all fastmath flags. With nnan and ninf, we can
just check for a 0 maximum. With only nnan, we have to check for both
cases separately.

show more ...

[mlir] Fix a warning

This patch fixes:

mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:964:26:
error: missing 'typename' prior to dependent type name Op::Adaptor;
implicit 'typena

[mlir] Fix a warning

This patch fixes:

mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:964:26:
error: missing 'typename' prior to dependent type name Op::Adaptor;
implicit 'typename' is a C++20 extension
[-Werror,-Wc++20-extensions]

show more ...

Fix Tan inaccuracies on extreme complex inputs. (#92443)

Specifically, those with small/large absolute values. This ports
https://github.com/openxla/xla/pull/10525 and was verified with XLA's
test

Fix Tan inaccuracies on extreme complex inputs. (#92443)

Specifically, those with small/large absolute values. This ports
https://github.com/openxla/xla/pull/10525 and was verified with XLA's
test suite.

show more ...

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change rem

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.

show more ...

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157

show more ...

[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.

[mlir][complex] Fastmath flag for complex angle (#88658)

See
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

Fix complex tanh overflows. (#88708)

This ports the XLA lowering and was verified using XLA's
exhaustive_unary_test_complex test.

Fix rsqrt inaccuracies. (#88707)

The current lowering has issues with large/subnormal values. This po
XLA's lowering and was verified using XLA's test suite and the
MLIR-based emitters.

This up

Fix rsqrt inaccuracies. (#88707)

The current lowering has issues with large/subnormal values. This po
XLA's lowering and was verified using XLA's test suite and the
MLIR-based emitters.

This updates https://github.com/llvm/llvm-project/pull/88691 to also
update the correctness test for rsqrt(0). I checked C++ and Python, they
both agree the result should be (inf, nan). Updated the correctness test
to match this.

show more ...

Revert "Fix rsqrt inaccuracies." (#88705)

Reverts llvm/llvm-project#88691

Fix rsqrt inaccuracies. (#88691)

The current lowering has issues with large/subnormal values. This ports
XLA's lowering and was verified using XLA's test suite and the
MLIR-based emitters.

[mlir][complex] Fastmath flag support for complex.tanh (#88571)

Fix overflows in complex sqrt lowering. (#88480)

This ports XLA's complex sqrt lowering. The accuracy was tested with its
exhaustive_unary_test_complex test.

Note: rsqrt is still broken.

Fix complex power for large inputs. (#88387)

For example, 1e30^1.2 currently overflows.

Also forward fastmath flags.

This ports XLA's logic and was verified with its test suite. Note that
rsq

Fix complex power for large inputs. (#88387)

For example, 1e30^1.2 currently overflows.

Also forward fastmath flags.

This ports XLA's logic and was verified with its test suite. Note that
rsqrt and sqrt are still broken.

show more ...

Fix complex abs corner cases. (#88373)

The current implementation fails for very small and very large values.
For example, (0, -inf) should return inf, but it returns -inf.

This ports the logic

Fix complex abs corner cases. (#88373)

The current implementation fails for very small and very large values.
For example, (0, -inf) should return inf, but it returns -inf.

This ports the logic used in XLA. Tested with XLA's
exhaustive_binary_test_f32_f64.

show more ...

Fix complex log1p accuracy with large abs values. (#88364)

This ports openxla/xla#10503 by @pearu. In addition to the filecheck
test here, the accuracy was tested with XLA's complex_unary_op_test a

Fix complex log1p accuracy with large abs values. (#88364)

This ports openxla/xla#10503 by @pearu. In addition to the filecheck
test here, the accuracy was tested with XLA's complex_unary_op_test and
its MLIR emitters.

This is a fixed version of
https://github.com/llvm/llvm-project/pull/88260. The previous version
relied on implementation-specific behavior in the order of evaluation of
maxAbsOfRealPlusOneAndImagMinusOne's operands.

show more ...

Revert "Fix complex log1p accuracy with large abs values." (#88290)

Reverts llvm/llvm-project#88260

The test fails on the GCC7 buildbot.

Fix complex log1p accuracy with large abs values. (#88260)

This ports https://github.com/openxla/xla/pull/10503 by @pearu. The new
implementation matches mpmath's results for most inputs, see cavea

Fix complex log1p accuracy with large abs values. (#88260)

This ports https://github.com/openxla/xla/pull/10503 by @pearu. The new
implementation matches mpmath's results for most inputs, see caveats in
the linked pull request. In addition to the filecheck test here, the
accuracy was tested with XLA's complex_unary_op_test and its MLIR
emitters.

show more ...

[mlir][complex] Support fast math flag for complex.tan op (#87919)

See
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

[mlir][complex] Support fast math flag for complex.sign op (#87148)

We are going to support the fast math flag given in `complex.sign` op in
the conversion to standard dialect.

See:
https://dis

[mlir][complex] Support fast math flag for complex.sign op (#87148)

We are going to support the fast math flag given in `complex.sign` op in
the conversion to standard dialect.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

show more ...

[mlir][complex] Fastmath flag for the trigonometric ops in complex (#85563)

Support Fastmath flag to convert trigonometric ops in the complex
dialect.

See:
https://discourse.llvm.org/t/rfc-fast

[mlir][complex] Fastmath flag for the trigonometric ops in complex (#85563)

Support Fastmath flag to convert trigonometric ops in the complex
dialect.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

show more ...

[mlir][complex] Support Fastmath flag in conversion of complex.sqrt to standard (#85019)

When converting complex.sqrt op to standard, we need to keep the fast
math flag given to the op.

See:
ht

[mlir][complex] Support Fastmath flag in conversion of complex.sqrt to standard (#85019)

When converting complex.sqrt op to standard, we need to keep the fast
math flag given to the op.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

show more ...