Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, 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 |
|
#
84cc1865 |
| 05-Aug-2024 |
Nikhil Kalra <nikhil.kalra@gmail.com> |
[mlir] Support DialectRegistry extension comparison (#101119)
`PassManager::run` loads the dependent dialects for each pass into the
current context prior to invoking the individual passes. If the
[mlir] Support DialectRegistry extension comparison (#101119)
`PassManager::run` loads the dependent dialects for each pass into the
current context prior to invoking the individual passes. If the
dependent dialect is already loaded into the context, this should be a
no-op. However, if there are extensions registered in the
`DialectRegistry`, the dependent dialects are unconditionally registered
into the context.
This poses a problem for dynamic pass pipelines, however, because they
will likely be executing while the context is in an immutable state
(because of the parent pass pipeline being run).
To solve this, we'll update the extension registration API on
`DialectRegistry` to require a type ID for each extension that is
registered. Then, instead of unconditionally registered dialects into a
context if extensions are present, we'll check against the extension
type IDs already present in the context's internal `DialectRegistry`.
The context will only be marked as dirty if there are net-new extension
types present in the `DialectRegistry` populated by
`PassManager::getDependentDialects`.
Note: this PR removes the `addExtension` overload that utilizes
`std::function` as the parameter. This is because `std::function` is
copyable and potentially allocates memory for the contained function so
we can't use the function pointer as the unique type ID for the
extension.
Downstream changes required:
- Existing `DialectExtension` subclasses will need a type ID to be
registered for each subclass. More details on how to register a type ID
can be found here:
https://github.com/llvm/llvm-project/blob/8b68e06731e0033ed3f8d6fe6292ae671611cfa1/mlir/include/mlir/Support/TypeID.h#L30
- Existing uses of the `std::function` overload of `addExtension` will
need to be refactored into dedicated `DialectExtension` classes with
associated type IDs. The attached `std::function` can either be inlined
into or called directly from `DialectExtension::apply`.
---------
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
2c1ae801 |
| 19-Jun-2024 |
donald chen <chenxunyu1993@gmail.com> |
[mlir][side effect] refactor(*): Include more precise side effects (#94213)
This patch adds more precise side effects to the current ops with memory
effects, allowing us to determine which OpOperan
[mlir][side effect] refactor(*): Include more precise side effects (#94213)
This patch adds more precise side effects to the current ops with memory
effects, allowing us to determine which OpOperand/OpResult/BlockArgument
the
operation reads or writes, rather than just recording the reading and
writing
of values. This allows for convenient use of precise side effects to
achieve
analysis and optimization.
Related discussions:
https://discourse.llvm.org/t/rfc-add-operandindex-to-sideeffect-instance/79243
show more ...
|
Revision tags: 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
87633432 |
| 08-Oct-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] Update empty_tensor_elimination transform op (#68497)
The empty tensor elimination pass semantics have changed recently: when
applied to a module, the One-Shot Module Analysis
[mlir][bufferization] Update empty_tensor_elimination transform op (#68497)
The empty tensor elimination pass semantics have changed recently: when
applied to a module, the One-Shot Module Analysis is run. Otherwise, the
regular One-Shot Analysis is run. The latter one is slightly different
because it ignores function boundaries and treats function block
arguments as "read-only".
This commit updates the transform dialect op to behave in the same way.
show more ...
|
#
5958043e |
| 05-Oct-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] Add `dump_alias_sets` option to transform op (#68289)
Add `dump_alias_sets` to `transform.bufferization.one_shot_bufferize`.
This option is useful for debugging. Also improve
[mlir][bufferization] Add `dump_alias_sets` option to transform op (#68289)
Add `dump_alias_sets` to `transform.bufferization.one_shot_bufferize`.
This option is useful for debugging. Also improve the verifier to ensure
that `test_analysis_only` is set when other debugging flags are enabled.
show more ...
|
Revision tags: llvmorg-17.0.2 |
|
#
65341b09 |
| 20-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization][NFC] Move memref specific implementation of AllocationOpInterface to memref dialect directory (#66637)
Follow-up on #65578
|
Revision tags: llvmorg-17.0.1 |
|
#
6bf043e7 |
| 18-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute (#66619)
This commit removes the deallocation capabilities of
one-shot-buffe
[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute (#66619)
This commit removes the deallocation capabilities of
one-shot-bufferization. One-shot-bufferization should never deallocate
any memrefs as this should be entirely handled by the
ownership-based-buffer-deallocation pass going forward. This means the
`allow-return-allocs` pass option will default to true now,
`create-deallocs` defaults to false and they, as well as the escape
attribute indicating whether a memref escapes the current region, will
be removed. A new `allow-return-allocs-from-loops` option is added as a
temporary workaround for some bufferization limitations.
show more ...
|
Revision tags: llvmorg-17.0.0 |
|
#
a1ef5a94 |
| 14-Sep-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] Empty tensor elimination based on SubsetOpInterface (#65766)
This commit generalizes empty tensor elimination to operate on subset
ops. No new test cases are added because all
[mlir][bufferization] Empty tensor elimination based on SubsetOpInterface (#65766)
This commit generalizes empty tensor elimination to operate on subset
ops. No new test cases are added because all current subset ops were
already supported previously. From this perspective, this change is NFC.
A new interface method (and a helper method) are added to
`SubsetInsertionOpInterface` to build the subset of the destination
tensor.
show more ...
|
#
c199f7dc |
| 13-Sep-2023 |
Martin Erhart <merhart@google.com> |
Revert "[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute"
This reverts commit 6a91dfedeb956dfa092a6a3f411e8b02f0d5d289.
This
Revert "[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute"
This reverts commit 6a91dfedeb956dfa092a6a3f411e8b02f0d5d289.
This caused problems in downstream projects. We are reverting to give them more time for integration.
show more ...
|
#
6a91dfed |
| 12-Sep-2023 |
Martin Erhart <merhart@google.com> |
[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute
This is the first commit in a series with the goal to rework the BufferDeallo
[mlir][bufferization] Remove allow-return-allocs and create-deallocs pass options, remove bufferization.escape attribute
This is the first commit in a series with the goal to rework the BufferDeallocation pass. Currently, this pass heavily relies on copies to perform correct deallocations, which leads to very slow code and potentially high memory usage. Additionally, there are unsupported cases such as returning memrefs which this series of commits aims to add support for as well.
This first commit removes the deallocation capabilities of one-shot-bufferization.One-shot-bufferization should never deallocate any memrefs as this should be entirely handled by the buffer-deallocation pass going forward. This means the allow-return-allocs pass option will default to true now, create-deallocs defaults to false and they, as well as the escape attribute indicating whether a memref escapes the current region, will be removed.
The documentation should w.r.t. these pass option changes should also be updated in this commit.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D156662
show more ...
|
Revision tags: llvmorg-17.0.0-rc4 |
|
#
34a35a8b |
| 31-Aug-2023 |
Martin Erhart <merhart@google.com> |
[mlir] Move FunctionInterfaces to Interfaces directory and inherit from CallableOpInterface
Functions are always callable operations and thus every operation implementing the `FunctionOpInterface` a
[mlir] Move FunctionInterfaces to Interfaces directory and inherit from CallableOpInterface
Functions are always callable operations and thus every operation implementing the `FunctionOpInterface` also implements the `CallableOpInterface`. The only exception was the FuncOp in the toy example. To make implementation of the `FunctionOpInterface` easier, this commit lets `FunctionOpInterface` inherit from `CallableOpInterface` and merges some of their methods. More precisely, the `CallableOpInterface` has methods to get the argument and result attributes and a method to get the result types of the callable region. These methods are always implemented the same way as their analogues in `FunctionOpInterface` and thus this commit moves all the argument and result attribute handling methods to the callable interface as well as the methods to get the argument and result types. The `FuntionOpInterface` then does not have to declare them as well, but just inherits them from the `CallableOpInterface`. Adding the inheritance relation also required to move the `FunctionOpInterface` from the IR directory to the Interfaces directory since IR should not depend on Interfaces.
Reviewed By: jpienaar, springerm
Differential Revision: https://reviews.llvm.org/D157988
show more ...
|
#
55e38579 |
| 22-Aug-2023 |
Xiaolei Shi <xiaoleis@nvidia.com> |
Make buffer hoisting/promotion passes use AllocationOpInterface
This update implements the usage of AllocationOpInterface in the buffer hoisting/promotion passes. Two interface methods, namely `getH
Make buffer hoisting/promotion passes use AllocationOpInterface
This update implements the usage of AllocationOpInterface in the buffer hoisting/promotion passes. Two interface methods, namely `getHoistingKind` and `buildPromotedAlloc`, have been added. The former indicates which kind of hoisting (loop, block) an allocation operation supports, while the latter builds a stack allocation operation for promotable allocations used by the promote-buffers-to-stack pass.
This update makes these passes be functional for user customized allocation operation.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D158398
show more ...
|
Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
98770ecd |
| 14-Jul-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] Add `buffer_loop_hoisting` transform op
This op hoists buffer allocation from loops.
Differential Revision: https://reviews.llvm.org/D155289
|
#
88f4292a |
| 14-Jul-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][bufferization] OneShotBufferizeOp: Add options to use linalg.copy
This new option allows users to specify a custom memcpy op.
Differential Revision: https://reviews.llvm.org/D155280
|
#
c63d2b2c |
| 20-Jun-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][transform] Add TransformRewriter
All `apply` functions now have a `TransformRewriter &` parameter. This rewriter should be used to modify the IR. It has a `TrackingListener` attached and upda
[mlir][transform] Add TransformRewriter
All `apply` functions now have a `TransformRewriter &` parameter. This rewriter should be used to modify the IR. It has a `TrackingListener` attached and updates the internal handle-payload mappings based on rewrites.
Implementations no longer need to create their own `TrackingListener` and `IRRewriter`. Error checking is integrated into `applyTransform`. Tracking listener errors are reported only for ops with the `ReportTrackingListenerFailuresOpTrait` trait attached, allowing for a gradual migration. Furthermore, errors can be silenced with an op attribute.
Additional API will be added to `TransformRewriter` in subsequent revisions. This revision just adds an "empty" `TransformRewriter` class and updates all `apply` implementations.
Differential Revision: https://reviews.llvm.org/D152427
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
2f3ac28c |
| 17-May-2023 |
Alex Zinenko <zinenko@google.com> |
[mlir] don't hardcode PDL_Operation in Transform dialect extensions
Update operations in Transform dialect extensions defined in the Affine, GPU, MemRef and Tensor dialects to use the more generic `
[mlir] don't hardcode PDL_Operation in Transform dialect extensions
Update operations in Transform dialect extensions defined in the Affine, GPU, MemRef and Tensor dialects to use the more generic `TransformHandleTypeInterface` type constraint instead of hardcoding `PDL_Operation`. See https://discourse.llvm.org/t/rfc-type-system-for-the-transform-dialect/65702 for motivation.
Remove the dependency on PDLDialect from these extensions.
Update tests to use `!transform.any_op` instead of `!pdl.operation`.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D150781
show more ...
|
Revision tags: llvmorg-16.0.4 |
|
#
0e37ef08 |
| 15-May-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][transform] Use TrackingListener-aware iterator for getPayloadOps
Instead of returning an `ArrayRef<Operation *>`, return at iterator that skips ops that were erased/replaced while iterating o
[mlir][transform] Use TrackingListener-aware iterator for getPayloadOps
Instead of returning an `ArrayRef<Operation *>`, return at iterator that skips ops that were erased/replaced while iterating over the payload ops.
This fixes an issue in conjuction with TrackingListener, where a tracked op was erased during the iteration. Elements may not be removed from an array while iterating over it; this invalidates the iterator.
When ops are erased/removed via `replacePayloadOp`, they are not immediately removed from the mappings data structure. Instead, they are set to `nullptr`. `nullptr`s are not enumerated by `getPayloadOps`. At the end of each transformation, `nullptr`s are removed from the mapping data structure.
Differential Revision: https://reviews.llvm.org/D149847
show more ...
|
#
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 |
|
#
75ef84bf |
| 12-Apr-2023 |
Oleg Shyshkov <shyshkov@google.com> |
[mlir][bufferization] Make function boundary type convertion logic dynamic.
Having to choose from only static or dynamic layout for all function is limiting.
Differential Revision: https://reviews.
[mlir][bufferization] Make function boundary type convertion logic dynamic.
Having to choose from only static or dynamic layout for all function is limiting.
Differential Revision: https://reviews.llvm.org/D148074
show more ...
|
#
1ccd8cd6 |
| 06-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][bufferization] Add bufferization.eliminate_empty_tensors transform op
Differential Revision: https://reviews.llvm.org/D144401
|
#
3f7959ea |
| 06-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][bufferize] Simplify one_shot_bufferize transform op
Restrict the op to functions and modules. Such ops are modified in-place. The transform now consumes the handle and produces a new handle.
[mlir][bufferize] Simplify one_shot_bufferize transform op
Restrict the op to functions and modules. Such ops are modified in-place. The transform now consumes the handle and produces a new handle. The `target_is_module` attribute is no longer needed because a result handle is produced in either case.
Differential Revision: https://reviews.llvm.org/D147446
show more ...
|
Revision tags: llvmorg-16.0.1, 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 |
|
#
0242b962 |
| 23-Jan-2023 |
Alex Zinenko <zinenko@google.com> |
[mlir] more side effect verification in transform dialect
Add a verifier checking that if a transform operation consumes a handle (which is associated with a payload operation being erased or recrea
[mlir] more side effect verification in transform dialect
Add a verifier checking that if a transform operation consumes a handle (which is associated with a payload operation being erased or recreated), it also indicates modification of the payload IR. This hasn't been consistent in the past because of the "no-aliasing" assumption where we couldn't have had more than one handle to an operation, requiring some handle-manipulation operations, such as `transform.merge_handles` to consume their operands. That assumption has been liften and it is no longer necessary for these operations to consume handles and thus make the life harder for the clients.
Additionally, remove TransformEffects.td that uses the ODS mechanism for indicating side effects that works only for operands and results. It was being used incorrectly to also indicate effects on the payload IR, not assocaited with any IR value, and lacked the consume/produce semantics available via helpers in C++.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D142361
show more ...
|
Revision tags: llvmorg-15.0.7 |
|
#
4b455a71 |
| 03-Jan-2023 |
Alex Zinenko <zinenko@google.com> |
[mlir] adapt TransformEachOpTrait to parameter values
Adapt the implementation of TransformEachOpTrait to the existence of parameter values recently introduced into the transform dialect. In particu
[mlir] adapt TransformEachOpTrait to parameter values
Adapt the implementation of TransformEachOpTrait to the existence of parameter values recently introduced into the transform dialect. In particular, allow `applyToOne` hooks to return a list containing a mix of `Operation *` that will be associated with handles and `Attribute` that will be associated with parameter values by the trait implementation of the transform interface's `apply` method.
Disentangle the "transposition" of the list of per-payload op partial results to decrease its overall complexity and detemplatize the code that doesn't really need templates. This removes the poorly documented special handling for single-result ops with TransformEachOpTrait that could have assigned null pointer values to handles.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D140979
show more ...
|
#
e7d0cc76 |
| 14-Dec-2022 |
Lorenzo Chelini <l.chelini@icloud.com> |
[MLIR][Bufferization] Introduce `EmptyTensorToAllocTensorOp`
Introduce a new transform operation to replace `tensor.empty` with `alloc_tensor` operations. The operation is a pass-through if the targ
[MLIR][Bufferization] Introduce `EmptyTensorToAllocTensorOp`
Introduce a new transform operation to replace `tensor.empty` with `alloc_tensor` operations. The operation is a pass-through if the target operation is already a `alloc_tensor`; otherwise, it expects a `tensor.empty` as a target. Currently, it does not return any results.
The operation is expected to run before `one_shot_bufferize` as `one_shot_bufferize` rejects `tensor.empty`.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D140026
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5 |
|
#
c780184a |
| 11-Nov-2022 |
Lorenzo Chelini <l.chelini@icloud.com> |
[MLIR][Transform] Expose map layout option in `OneShotBufferizeOp`
Expose `function-boundary-type-conversion` in `OneShotBufferizeOp`. To reuse options between passes and transform operations, creat
[MLIR][Transform] Expose map layout option in `OneShotBufferizeOp`
Expose `function-boundary-type-conversion` in `OneShotBufferizeOp`. To reuse options between passes and transform operations, create a `BufferizationEnums.td`.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D137833
show more ...
|
Revision tags: 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 |
|
#
333ee218 |
| 21-Jul-2022 |
Alex Zinenko <zinenko@google.com> |
[mlir] Transform dialect: separate dependent and generated dialects
In the Transform dialect extensions, provide the separate mechanism to declare dependent dialects (the dialects the transform IR d
[mlir] Transform dialect: separate dependent and generated dialects
In the Transform dialect extensions, provide the separate mechanism to declare dependent dialects (the dialects the transform IR depends on) and the generated dialects (the dialects the payload IR may be transformed into). This allows the Transform dialect clients that are only constructing the transform IR to avoid loading the dialects relevant for the payload IR along with the Transform dialect itself, thus decreasing the build/link time.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D130289
show more ...
|