[mlir][complex] Canonicalize complex.div by one (#85513)

We can canonicalize the complex.div if the divisor is one (real = 1.0,
imag = 0.0) with the input number itself.

Ref: https://www.cuemath

[mlir][complex] Canonicalize complex.div by one (#85513)

We can canonicalize the complex.div if the divisor is one (real = 1.0,
imag = 0.0) with the input number itself.

Ref: https://www.cuemath.com/numbers/division-of-complex-numbers/

show more ...

[mlir][complex] Allow integer element types in `complex.constant` ops (#74564)

The op used to support only float element types. This was inconsistent
with `ConstantOp::isBuildableWith`, which allow

[mlir][complex] Allow integer element types in `complex.constant` ops (#74564)

The op used to support only float element types. This was inconsistent
with `ConstantOp::isBuildableWith`, which allows integer element types.
The complex type allows any float/integer element type.

Note: The other complex dialect ops do not support non-float element
types yet. The main purpose of this change to fix
`Tensor/canonicalize.mlir`, which is currently failing when verifying
the IR after each pattern application (#74270).

```
within split at mlir/test/Dialect/Tensor/canonicalize.mlir:231 offset :8:15: error: 'complex.constant' op result #0 must be complex type with floating-point elements, but got 'complex<i32>'
%complex1 = tensor.extract %c1[] : tensor<complex<i32>>
^
within split at mlir/test/Dialect/Tensor/canonicalize.mlir:231 offset :8:15: note: see current operation: %0 = "complex.constant"() <{value = [1 : i32, 2 : i32]}> : () -> complex<i32>
"func.func"() <{function_type = () -> tensor<3xcomplex<i32>>, sym_name = "extract_from_elements_complex_i"}> ({
%0 = "complex.constant"() <{value = [1 : i32, 2 : i32]}> : () -> complex<i32>
%1 = "arith.constant"() <{value = dense<(3,2)> : tensor<complex<i32>>}> : () -> tensor<complex<i32>>
%2 = "arith.constant"() <{value = dense<(1,2)> : tensor<complex<i32>>}> : () -> tensor<complex<i32>>
%3 = "tensor.extract"(%1) : (tensor<complex<i32>>) -> complex<i32>
%4 = "tensor.from_elements"(%0, %3, %0) : (complex<i32>, complex<i32>, complex<i32>) -> tensor<3xcomplex<i32>>
"func.return"(%4) : (tensor<3xcomplex<i32>>) -> ()
}) : () -> ()
```

show more ...

[mlir][doc] Remove duplicate syntax formats (#73343)

Some operations defined their syntax both in the documentation and via
`assemblyFormat`. This leads to two `Syntax:` subheadings in the
documen

[mlir][doc] Remove duplicate syntax formats (#73343)

Some operations defined their syntax both in the documentation and via
`assemblyFormat`. This leads to two `Syntax:` subheadings in the
documentation, see for example the documentation for
[`arith.maximumf`](https://mlir.llvm.org/docs/Dialects/ArithOps/#arithmaximumf-arithmaximumfop).
Since the `assemblyFormat` is used to generate the actual parsers and
printer implementations, this PR suggest to remove the manual syntax
descriptions.

show more ...

[mlir][complex] Initial support for FastMath flag when converting to LLVM

This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](http

[mlir][complex] Initial support for FastMath flag when converting to LLVM

This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](https://reviews.llvm.org/rGb56e65d31825fe4a1ae02fdcbad58bb7993d63a7), `fastmath` attributes in the complex dialect are directly mapped to the corresponding LLVM fastmath flags.

In this diff,

- Definition of FastMathAttr as a custom attribute in the Complex dialect that inherits from the EnumAttr class.
- Definition of ComplexFastMathInterface, which is an interface that is implemented by operations that have a complex::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and arithmetic operations in the Complex dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags

NOT in this diff (but planned and progressively implemented):

- Documentation of flag meanings
- Support the fastmath flag conversion to Arith dialect
- Folding/rewrite implementations that are enabled by fastmath flags (although it's the original motivation to support the flag)

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

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D156310

show more ...

[mlir][complex] Add a `complex.bitcast` operation

Converting between a complex<f32> to i64 could be useful for handling interop
between the `arith` and `complex` dialects.

Reviewed By: jpienaar

Di

[mlir][complex] Add a `complex.bitcast` operation

Converting between a complex<f32> to i64 could be useful for handling interop
between the `arith` and `complex` dialects.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D154663

show more ...

[mlir][complex] Canonicalize complex.mul with 1 and 0

We can fold the complex.mul if the right value is obvious 1 or 0.

Differential Revision: https://reviews.llvm.org/D153606

[mlir][complex] Canonicalize re/im(neg(create))

When can just convert this to arith.negf.

Reviewed By: kuhar

Differential Revision: https://reviews.llvm.org/D151633

[mlir] Move casting method calls to function calls

The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in

[mlir] Move casting method calls to function calls

The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in addition to defining methods with the same name.
This change continues the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

This commit attempts to update all occurrences of the casts in .td
files, although it is likely that a couple were missed.

Context:
- https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…"
- Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443

Implementation:
Unfortunatley, this was not automated, but was handled by mindlessly
going to next occurrences of patterns, selecting the piece of code to
be moved into the function call, and running a vim macro over the span
of around 4 hours.

Differential Revision: https://reviews.llvm.org/D150199

show more ...

[mlir][NFC] Remove trailing whitespaces from `*.td` and `*.mlir` files.

This is generated by running

```
sed --in-place 's/[[:space:]]\+$//' mlir/**/*.td
sed --in-place 's/[[:space:]]\+$//' mlir/**

[mlir][NFC] Remove trailing whitespaces from `*.td` and `*.mlir` files.

This is generated by running

```
sed --in-place 's/[[:space:]]\+$//' mlir/**/*.td
sed --in-place 's/[[:space:]]\+$//' mlir/**/*.mlir
```

Reviewed By: rriddle, dcaballe

Differential Revision: https://reviews.llvm.org/D138866

show more ...

Introduce a ConditionallySpeculatable op interface

This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads:

Introduce a ConditionallySpeculatable op interface

This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads:

1. https://discourse.llvm.org/t/semantics-modeling-undefined-behavior-and-side-effects/4812
2. https://discourse.llvm.org/t/rfc-mark-tensor-dim-and-memref-dim-as-side-effecting/65729

This patch in particular does the following:

1. Introduces a ConditionallySpeculatable OpInterface that dynamically determines whether an Operation can be speculated.
2. Re-defines `NoSideEffect` to allow undefined behavior, making it necessary but not sufficient for speculation. Also renames it to `NoMemoryEffect`.
3. Makes LICM respect the above semantics.
4. Changes all ops tagged with `NoSideEffect` today to additionally implement ConditionallySpeculatable and mark themselves as always speculatable. This combined trait is named `Pure`. This makes this change NFC.

For out of tree dialects:

1. Replace `NoSideEffect` with `Pure` if the operation does not have any memory effects, undefined behavior or infinite loops.
2. Replace `NoSideEffect` with `NoSideEffect` otherwise.

The next steps in this process are (I'm proposing to do these in upcoming patches):

1. Update operations like `tensor.dim`, `memref.dim`, `scf.for`, `affine.for` to implement a correct hook for `ConditionallySpeculatable`. I'm also happy to update ops in other dialects if the respective dialect owners would like to and can give me some pointers.
2. Update other passes that speculate operations to consult `ConditionallySpeculatable` in addition to `NoMemoryEffect`. I could not find any other than LICM on a quick skim, but I could have missed some.
3. Add some documentation / FAQs detailing the differences between side effects, undefined behavior, speculatabilty.

Reviewed By: rriddle, mehdi_amini

Differential Revision: https://reviews.llvm.org/D135505

show more ...

[mlir][complex] Canonicalization for complex.sub adding same numbers

Canonicalization for complex.sub adding same numbers. This canonicalization supports the case like complex.sub(complex.add(a, b),

[mlir][complex] Canonicalization for complex.sub adding same numbers

Canonicalization for complex.sub adding same numbers. This canonicalization supports the case like complex.sub(complex.add(a, b), b) -> a.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D133397

show more ...

[mlir][complex] Canonicalize consecutive complex.conj

We can canonicalize consecutive complex.conj just by removing all conjugate operations.

Reviewed By: pifon2a

Differential Revision: https://re

[mlir][complex] Canonicalize consecutive complex.conj

We can canonicalize consecutive complex.conj just by removing all conjugate operations.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D130684

show more ...

[mlir][complex] Inverse canonicalization between exp and log

We can canonicalize consecutive complex.exp and complex.log which are inverse functions each other.

Reviewed By: bixia

Differential Rev

[mlir][complex] Inverse canonicalization between exp and log

We can canonicalize consecutive complex.exp and complex.log which are inverse functions each other.

Reviewed By: bixia

Differential Revision: https://reviews.llvm.org/D128966

show more ...

[mlir][complex] Canonicalization for consecutive complex.neg

Consecutive complex.neg are redundant so that we can canonicalize them to the original operands.

Reviewed By: pifon2a

Differential Revi

[mlir][complex] Canonicalization for consecutive complex.neg

Consecutive complex.neg are redundant so that we can canonicalize them to the original operands.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D128781

show more ...

[mlir][complex] Canonicalization for consecutive complex.add and sub

Add basic canonicalization for consecutive complex.add and sub operations.

Reviewed By: pifon2a

Differential Revision: https://

[mlir][complex] Canonicalization for consecutive complex.add and sub

Add basic canonicalization for consecutive complex.add and sub operations.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D128702

show more ...

[mlir][complex] complex.arg op to calculate the angle of complex number

Add complex.arg op which calculates the angle of complex number. The op name is inspired by the function carg in libm.

See: h

[mlir][complex] complex.arg op to calculate the angle of complex number

Add complex.arg op which calculates the angle of complex number. The op name is inspired by the function carg in libm.

See: https://sourceware.org/newlib/libm.html#carg

Differential Revision: https://reviews.llvm.org/D128531

show more ...

[mlir][complex] Add complex.conj op

Add complex.conj op to calculate the complex conjugate which is widely used for the mathematical operation on the complex space.

Reviewed By: pifon2a

Differenti

[mlir][complex] Add complex.conj op

Add complex.conj op to calculate the complex conjugate which is widely used for the mathematical operation on the complex space.

Reviewed By: pifon2a

Differential Revision: https://reviews.llvm.org/D127181

show more ...

[mlir][complex] Add tan op for complex dialect

Add tangent operation for complex dialect. This is the follow-up change of https://reviews.llvm.org/D126521

Differential Revision: https://reviews.llv

[mlir][complex] Add tan op for complex dialect

Add tangent operation for complex dialect. This is the follow-up change of https://reviews.llvm.org/D126521

Differential Revision: https://reviews.llvm.org/D126685

show more ...

[mlir] Add `complex.atan2` operation.

Differential Revision: https://reviews.llvm.org/D126357

[mlir] Add Expm1 tp ComplexOps.td.

Differential Revision: https://reviews.llvm.org/D126206

[mlir] Add RSqrt tp ComplexOps.td.

Differential Revision: https://reviews.llvm.org/D126202

[mlir][complex] Add pow/sqrt/tanh ops and lowering to libm

Lowering through libm gives us a baseline version, even though it's not
going to be particularly fast. This is similar to what we do for so

[mlir][complex] Add pow/sqrt/tanh ops and lowering to libm

Lowering through libm gives us a baseline version, even though it's not
going to be particularly fast. This is similar to what we do for some
math dialect ops.

Differential Revision: https://reviews.llvm.org/D125550

show more ...

[mlir] Add sin & cos ops to complex dialect

Also adds conversions for those ops to math + arith.

Differential Revision: https://reviews.llvm.org/D124773

[mlir][NFC] Update remaining dialect operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

Differential Revision: https://reviews.llvm.org/

[mlir][NFC] Update remaining dialect operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

Differential Revision: https://reviews.llvm.org/D118829

show more ...

Remove OpTrait, AttrTrait and TypeTrait

- Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait`
- Rename `OpTraitList` to `TraitList` and use it in a few places

The bulk of

Remove OpTrait, AttrTrait and TypeTrait

- Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait`
- Rename `OpTraitList` to `TraitList` and use it in a few places

The bulk of this change is a mechanical s/OpTrait/Trait/ throughout the codebase.

Reviewed By: rriddle, jpienaar, herhut

Differential Revision: https://reviews.llvm.org/D118543

show more ...