Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
2ff2e871 |
| 27-Nov-2024 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] Remove remaining dialect conversion-based infra parts (#114155)
This commit removes the last remaining components of the dialect
conversion-based bufferization passes.
Note
[mlir][bufferization] Remove remaining dialect conversion-based infra parts (#114155)
This commit removes the last remaining components of the dialect
conversion-based bufferization passes.
Note for LLVM integration: If you depend on these components, migrate to
One-Shot Bufferize or copy them to your codebase.
show more ...
|
Revision tags: llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, 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 |
|
#
dd450f08 |
| 07-Jan-2024 |
Matthias Springer <me@m-sp.org> |
[mlir][Interfaces][NFC] Move region loop detection to `RegionBranchOpInterface` (#77090)
`BufferPlacementTransformationBase::isLoop` checks if there a loop in
the region branching graph of an opera
[mlir][Interfaces][NFC] Move region loop detection to `RegionBranchOpInterface` (#77090)
`BufferPlacementTransformationBase::isLoop` checks if there a loop in
the region branching graph of an operation. This algorithm is similar to
`isRegionReachable` in the `RegionBranchOpInterface`. To avoid duplicate
code, `isRegionReachable` is generalized, so that it can be used to
detect region loops. A helper function
`RegionBranchOpInterface::hasLoop` is added.
This change also turns a recursive implementation into an iterative one,
which is the preferred implementation strategy in LLVM.
Also move the `isLoop` to `BufferOptimizations.cpp`, so that we can
gradually retire `BufferPlacementTransformationBase`. (This is so that
proper error handling can be added to `BufferViewFlowAnalysis`.)
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 |
|
#
8160bce9 |
| 14-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface (#66349)
This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations
[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface (#66349)
This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations which is useful when an op cannot implement the interfaces supported by default by the buffer deallocation pass (e.g., because they are not exactly compatible or because there are some additional semantics to it that would render the default implementations in buffer deallocation invalid, or because no interfaces exist for this
kind of behavior and it's not worth introducing one plus a default implementation in buffer deallocation). Additionally, it can also be used to provide more efficient handling for a specific op than the interface based default
implementations can.
show more ...
|
#
01334d1a |
| 14-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization] Add an ownership based buffer deallocation pass (#66337)
Add a new Buffer Deallocation pass with the intend to replace the old
one. For now it is added as a separate pass alon
[mlir][bufferization] Add an ownership based buffer deallocation pass (#66337)
Add a new Buffer Deallocation pass with the intend to replace the old
one. For now it is added as a separate pass alongside in order to allow
downstream users to migrate over gradually. This new pass has the goal
of inserting fewer clone operations and supporting additional use-cases.
Please refer to the Buffer Deallocation section in the updated
Bufferization.md file for more information on how this new pass works.
show more ...
|
#
520407a7 |
| 13-Sep-2023 |
Martin Erhart <merhart@google.com> |
Revert "[mlir][bufferization] Improve buffer deallocation pass"
This reverts commit 1bebb60a7565e5197d23120528f544b886b4d905.
This caused problems in downstream projects. We are reverting to give t
Revert "[mlir][bufferization] Improve buffer deallocation pass"
This reverts commit 1bebb60a7565e5197d23120528f544b886b4d905.
This caused problems in downstream projects. We are reverting to give them more time for integration.
show more ...
|
#
792caac0 |
| 13-Sep-2023 |
Martin Erhart <merhart@google.com> |
Revert "[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface"
This reverts commit 29d86175e6a5fe956147734229dca88822415b21.
This caused problems in downstream projects. We are reverti
Revert "[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface"
This reverts commit 29d86175e6a5fe956147734229dca88822415b21.
This caused problems in downstream projects. We are reverting to give them more time for integration.
show more ...
|
#
29d86175 |
| 12-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface
This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations which is
[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface
This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations which is useful when an op cannot implement the interfaces supported by default by the buffer deallocation pass (e.g., because they are not exactly compatible or because there are some additional semantics to it that would render the default implementations in buffer deallocation invalid, or because no interfaces exist for this kind of behavior and it's not worth introducing one plus a default implementation in buffer deallocation). Additionally, it can also be used to provide more efficient handling for a specific op than the interface based default implementations can.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D158756
show more ...
|
#
1bebb60a |
| 12-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization] Improve buffer deallocation pass
Add a new Buffer Deallocation pass replacing the old one with the goal of inserting fewer clone operations and supporting additional use-cases.
[mlir][bufferization] Improve buffer deallocation pass
Add a new Buffer Deallocation pass replacing the old one with the goal of inserting fewer clone operations and supporting additional use-cases. Please refer to the Buffer Deallocation section in the updated Bufferization.md file for more information on how this new pass works.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D158421
show more ...
|
Revision tags: llvmorg-17.0.0-rc4 |
|
#
4dd744ac |
| 30-Aug-2023 |
Markus Böck <markus.bock+llvm@nextsilicon.com> |
Reland "[mlir] Use a type for representing branch points in `RegionBranchOpInterface`"
This reverts commit b26bb30b467b996c9786e3bd426c07684d84d406.
|
#
b26bb30b |
| 29-Aug-2023 |
Markus Böck <markus.boeck02@gmail.com> |
Revert "[mlir] Use a type for representing branch points in `RegionBranchOpInterface`"
This reverts commit 024f562da67180b7be1663048c960b26c2cc16f8.
Forgot to update flang
|
#
024f562d |
| 29-Aug-2023 |
Markus Böck <markus.boeck02@gmail.com> |
[mlir] Use a type for representing branch points in `RegionBranchOpInterface`
The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt`
[mlir] Use a type for representing branch points in `RegionBranchOpInterface`
The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt` represents the parent op and `unsigned` is the region number. This doesn't give us any useful methods specific to region control flow and makes the code fragile to changes due to now taking the region number into account.
This patch introduces a new type called `RegionBranchPoint`, replacing all uses of `std::optional<unsigned>` in the interface. It can be implicitly constructed from a region or a `RegionSuccessor`, can be compared with a region to check whether the branch point is branching from the parent, adds `isParent` to check whether we are coming from a parent op and adds `RegionSuccessor::parent` as a descriptive way to indicate branching from the parent.
Differential Revision: https://reviews.llvm.org/D159116
show more ...
|
Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
5550c821 |
| 08-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.
Caveats include: - This clang-tidy script probably has more problems. - This only touches C++ code, so nothing that is being generated.
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 first patch was created with the following steps. The intention is to only do automated changes at first, so I waste less time if it's reverted, and so the first mass change is more clear as an example to other teams that will need to follow similar steps.
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: https://github.com/llvm/llvm-project/compare/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. 4. Some changes have been deleted for the following reasons: - Some files had a variable also named cast - Some files had not included a header file that defines the cast functions - Some files are definitions of the classes that have the casting methods, so the code still refers to the method instead of the function without adding a prefix or removing the method declaration at the same time.
``` 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
git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\ mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\ mlir/lib/**/IR/\ mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\ mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\ mlir/test/lib/Dialect/Test/TestTypes.cpp\ mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\ mlir/test/lib/Dialect/Test/TestAttributes.cpp\ mlir/unittests/TableGen/EnumsGenTest.cpp\ mlir/test/python/lib/PythonTestCAPI.cpp\ mlir/include/mlir/IR/ ```
Differential Revision: https://reviews.llvm.org/D150123
show more ...
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1 |
|
#
8bb5ca58 |
| 19-Mar-2023 |
Maya Amrami <mayaam88@gmail.com> |
[mlir] Support bufferization of arith.constant to memref.global with memory space
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D146381
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init |
|
#
0a81ace0 |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[mlir] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is pa
[mlir] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
a1fe1f5f |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[mlir] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optiona
[mlir] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.7 |
|
#
1a36588e |
| 04-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of ma
[mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
3b0dce5b |
| 16-Jul-2022 |
Kazu Hirata <kazu@google.com> |
Use value_or (NFC)
|
#
c27d8152 |
| 14-Jul-2022 |
Kazu Hirata <kazu@google.com> |
[mlir] Use value instead of getValue (NFC)
|
#
491d2701 |
| 13-Jul-2022 |
Kazu Hirata <kazu@google.com> |
[mlir] Use has_value instead of hasValue (NFC)
|
#
136d746e |
| 11-Jul-2022 |
Jacques Pienaar <jpienaar@google.com> |
[mlir] Flip accessors to prefixed form (NFC)
Another mechanical sweep to keep diff small for flip to _Prefixed.
|
#
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
#
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Don't use Optional::hasValue (NFC)
|
Revision tags: llvmorg-14.0.6 |
|
#
037f0995 |
| 20-Jun-2022 |
Kazu Hirata <kazu@google.com> |
[mlir] Don't use Optional::hasValue (NFC)
|
Revision tags: 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 |
|
#
af9f7d31 |
| 09-Mar-2022 |
Uday Bondhugula <uday@polymagelabs.com> |
NFC. Clean up memref utils library
NFC. Clean up memref utils library. This library had a single function that was completely misplaced. MemRefUtils is expected to be (also per its comment) a librar
NFC. Clean up memref utils library
NFC. Clean up memref utils library. This library had a single function that was completely misplaced. MemRefUtils is expected to be (also per its comment) a library providing analysis/transforms utilities on memref dialect ops or memref types. However, in reality it had a helper that was depended upon by the MemRef dialect, i.e., it was a helper for the dialect ops library and couldn't contain anything that itself depends on the MemRef dialect. Move the single method to the memref dialect that will now allow actual utilities depending on the memref dialect to be placed in it.
Put findDealloc in the `memref` namespace. This is a pure move.
Differential Revision: https://reviews.llvm.org/D121273
show more ...
|
#
06057248 |
| 08-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Add various includes currently transitively found in BuiltinOps.h
These includes are going to be removed from BuiltinOps.h in a followup when FuncOp is moved out of the Builtin dialect.
[mlir][NFC] Add various includes currently transitively found in BuiltinOps.h
These includes are going to be removed from BuiltinOps.h in a followup when FuncOp is moved out of the Builtin dialect. This commit pre-emptively adds those includes to simplify the patch moving FuncOp.
show more ...
|