History log of /llvm-project/mlir/lib/Dialect/Complex/IR/ComplexOps.cpp (Results 1 – 25 of 29)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# a5757c5b 19-Apr-2024 Christian Sigg <chsigg@users.noreply.github.com>

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

See https://mlir.llvm.org/

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

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

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3
# 08a321e1 26-Mar-2024 Kai Sasaki <lewuathe@gmail.com>

[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 ...


Revision tags: llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 16129937 07-Dec-2023 Matthias Springer <me@m-sp.org>

[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 ...


# 192439db 05-Dec-2023 Matthias Springer <me@m-sp.org>

[mlir][Complex] Fix bug in `MergeComplexBitcast` (#74271)

When two `complex.bitcast` ops are folded and the resulting bitcast is a
non-complex -> non-complex bitcast, an `arith.bitcast` should be

[mlir][Complex] Fix bug in `MergeComplexBitcast` (#74271)

When two `complex.bitcast` ops are folded and the resulting bitcast is a
non-complex -> non-complex bitcast, an `arith.bitcast` should be
generated. Otherwise, the generated `complex.bitcast` op is invalid.

Also remove a pattern that convertes non-complex -> non-complex
`complex.bitcast` ops to `arith.bitcast`. Such `complex.bitcast` ops are
invalid and should not appear in the input.

Note: This bug can only be triggered by running with `-debug` (which
will should intermediate IR that does not verify) or with
`MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS` (#74270).

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# a8df21f4 06-Jul-2023 Rob Suderman <suderman@google.com>

[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 ...


# 8d175b35 28-Jun-2023 Kai Sasaki <lewuathe@gmail.com>

[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


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5
# a1e78615 29-May-2023 Lei Zhang <antiagainst@gmail.com>

[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


# 68f58812 26-May-2023 Tres Popp <tpopp@google.com>

[mlir] Move casting calls from methods 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
functionali

[mlir] Move casting calls from methods 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 begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.

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:
This patch updates all remaining uses of the deprecated functionality in
mlir/. This was done with clang-tidy as described below and further
modifications to GPUBase.td and OpenMPOpsInterfaces.td.

Steps are described per line, as comments are removed by git:
0. Retrieve the change from the following to build clang-tidy with an
additional check:
main...tpopp:llvm-project:tidy-cast-check
1. Build clang-tidy
2. Run clang-tidy over your entire codebase while disabling all checks
and enabling the one relevant one. Run on all header files also.
3. Delete .inc files that were also modified, so the next build rebuilds
them to a pure state.

```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
-header-filter=mlir/ mlir/* -fix

rm -rf $BUILD_DIR/tools/mlir/**/*.inc
```

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

show more ...


Revision tags: llvmorg-16.0.4
# c1fa60b4 11-May-2023 Tres Popp <tpopp@google.com>

[mlir] Update method cast 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 a

[mlir] Update method cast 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 begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.

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:
This follows a previous patch that updated calls
`op.cast<T>()-> cast<T>(op)`. However some cases could not handle an
unprefixed `cast` call due to occurrences of variables named cast, or
occurring inside of class definitions which would resolve to the method.
All C++ files that did not work automatically with `cast<T>()` are
updated here to `llvm::cast` and similar with the intention that they
can be easily updated after the methods are removed through a
find-replace.

See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
for the clang-tidy check that is used and then update printed
occurrences of the function to include `llvm::` before.

One can then run the following:
```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
-export-fixes /tmp/cast/casts.yaml mlir/*\
-header-filter=mlir/ -fix

rm -rf $BUILD_DIR/tools/mlir/**/*.inc
```

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

show more ...


Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3
# cc4fb583 12-Feb-2023 Xiang Li <python3kgae@outlook.com>

[mlir] support complex type in DenseElementsAttr::get.

Fixes #60662 https://github.com/llvm/llvm-project/issues/60662

Allow ComplexType when create DenseElementsAttr.
Also allow build ConstantOp fo

[mlir] support complex type in DenseElementsAttr::get.

Fixes #60662 https://github.com/llvm/llvm-project/issues/60662

Allow ComplexType when create DenseElementsAttr.
Also allow build ConstantOp for integer complex.

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

show more ...


Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 7df76121 10-Jan-2023 Markus Böck <markus.boeck02@gmail.com>

[mlir][NFC] Migrate rest of the dialects to the new fold API


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5
# c9741baf 09-Nov-2022 Kai Sasaki <lewuathe@gmail.com>

[mlir][complex] Canonicalize complex.sub zero

Subtracting zero constant can be fold in no complex.sub operation.

Reviewed By: pifon2a

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


Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1
# ccf97505 07-Sep-2022 Kai Sasaki <lewuathe@gmail.com>

[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 ...


Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# e1795322 19-Jul-2022 Jeff Niu <jeff@modular.com>

[mlir] Remove types from attributes

This patch removes the `type` field from `Attribute` along with the
`Attribute::getType` accessor.

Going forward, this means that attributes in MLIR will no long

[mlir] Remove types from attributes

This patch removes the `type` field from `Attribute` along with the
`Attribute::getType` accessor.

Going forward, this means that attributes in MLIR will no longer have
types as a first-class concept. This patch lays the groundwork to
incrementally remove or refactor code that relies on generic attributes
being typed. The immediate impact will be on attributes that rely on
`Attribute` containing a type, such as `IntegerAttr`,
`DenseElementsAttr`, and `ml_program::ExternAttr`, which will now need
to define a type parameter on their storage classes. This will save
memory as all other attribute kinds will no longer contain a type.

Moreover, it will not be possible to generically query the type of an
attribute directly. This patch provides an attribute interface
`TypedAttr` that implements only one method, `getType`, which can be
used to generically query the types of attributes that implement the
interface. This interface can be used to retain the concept of a "typed
attribute". The ODS-generated accessor for a `type` parameter
automatically implements this method.

Next steps will be to refactor the assembly formats of certain operations
that rely on `parseAttribute(type)` and `printAttributeWithoutType` to
remove special handling of type elision until `type` can be removed from
the dialect parsing hook entirely; and incrementally remove uses of
`TypedAttr`.

Reviewed By: lattner, rriddle, jpienaar

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

show more ...


# 730cb822 29-Jul-2022 lewuathe <lewuathe@me.com>

[mlir][complex] Canonicalize complex.add zero

Adding complex value with 0 for real and imaginary part can be ignored.

NOTE: This type of canonicalization can be written in an easy and tidy format u

[mlir][complex] Canonicalize complex.add zero

Adding complex value with 0 for real and imaginary part can be ignored.

NOTE: This type of canonicalization can be written in an easy and tidy format using `complex.number` after constant op supports custom attribute.

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

show more ...


# bcd538ab 29-Jul-2022 lewuathe <lewuathe@me.com>

[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 ...


# 5148c685 03-Jul-2022 lewuathe <lewuathe@me.com>

[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 ...


# 01807095 29-Jun-2022 lewuathe <lewuathe@me.com>

[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 ...


# 036a6996 28-Jun-2022 lewuathe <lewuathe@me.com>

[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 ...


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1
# 1be88f5a 02-Feb-2022 River Riddle <riddleriver@gmail.com>

[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 ...


Revision tags: llvmorg-15-init
# 480cd4cb 25-Jan-2022 River Riddle <riddleriver@gmail.com>

[mlir] Move the complex support of std.constant to a new complex.constant operation

This is part of splitting up the standard dialect.

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


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# dee46d08 26-May-2021 Adrian Kuegel <akuegel@google.com>

[mlir] Fold complex.create(complex.re(op), complex.im(op))

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


# cb65419b 26-May-2021 Adrian Kuegel <akuegel@google.com>

[mlir] Simplify folding code (NFC)


# b99f892b 26-May-2021 Adrian Kuegel <akuegel@google.com>

[mlir] Fold complex.re(complex.create) and complex.im(complex.create)

This extends the folding we already have. A test needs to be adjusted.

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


Revision tags: llvmorg-12.0.1-rc1
# a28fe17d 20-May-2021 Adrian Kuegel <akuegel@google.com>

[mlir] Add EqualOp and NotEqualOp to complex dialect.


12