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