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, 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 |
|
#
971b8525 |
| 01-Apr-2024 |
Jakub Kuderski <jakub@nod-labs.com> |
[mlir][NFC] Simplify type checks with isa predicates (#87183)
For more context on isa predicates, see:
https://github.com/llvm/llvm-project/pull/83753.
|
#
5a9bdd85 |
| 20-Mar-2024 |
Oleksandr "Alex" Zinenko <zinenko@google.com> |
[mlir] split transform interfaces into a separate library (#85221)
Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialec
[mlir] split transform interfaces into a separate library (#85221)
Transform interfaces are implemented, direction or via extensions, in
libraries belonging to multiple other dialects. Those dialects don't
need to depend on the non-interface part of the transform dialect, which
includes the growing number of ops and transitive dependency footprint.
Split out the interfaces into a separate library. This in turn requires
flipping the dependency from the interface on the dialect that has crept
in because both co-existed in one library. The interface shouldn't
depend on the transform dialect either.
As a consequence of splitting, the capability of the interpreter to
automatically walk the payload IR to identify payload ops of a certain
kind based on the type used for the entry point symbol argument is
disabled. This is a good move by itself as it simplifies the interpreter
logic. This functionality can be trivially replaced by a
`transform.structured.match` operation.
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
fab2bb8b |
| 11-Mar-2024 |
Justin Lebar <justin.lebar@gmail.com> |
Add llvm::min/max_element and use it in llvm/ and mlir/ directories. (#84678)
For some reason this was missing from STLExtras.
|
Revision tags: 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 |
|
#
1609f1c2 |
| 14-Nov-2023 |
long.chen <lipracer@gmail.com> |
[mlir][affine][nfc] cleanup deprecated T.cast style functions (#71269)
detail see the docment: https://mlir.llvm.org/deprecation/
Not all changes are made manually, most of them are made through
[mlir][affine][nfc] cleanup deprecated T.cast style functions (#71269)
detail see the docment: https://mlir.llvm.org/deprecation/
Not all changes are made manually, most of them are made through a clang
tool I wrote https://github.com/lipracer/cpp-refactor.
show more ...
|
#
00c3c731 |
| 11-Nov-2023 |
spaceotter <zaimzet@gmail.com> |
[mlir][gpu] Separate the barrier elimination code from transform ops (#71762)
Allows the barrier elimination code to be run from C++ as well. The code
from transforms dialect is copied as-is, the p
[mlir][gpu] Separate the barrier elimination code from transform ops (#71762)
Allows the barrier elimination code to be run from C++ as well. The code
from transforms dialect is copied as-is, the pass and populate functions
have beed added at the end.
Co-authored-by: Eric Eaton <eric@nod-labs.com>
show more ...
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0 |
|
#
06918a96 |
| 05-Sep-2023 |
Lukas Sommer <lukas.sommer@codeplay.com> |
[MLIR][NFC] Mark barrier elimination helper static (#65303)
Make local helper functions static to avoid symbol name collision.
|
Revision tags: llvmorg-17.0.0-rc4 |
|
#
92f088d3 |
| 04-Sep-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][gpu][transform] Provide better error messages and avoid crashing in MapForallToBlocks.
This revision addresses issues surfaced in https://reviews.llvm.org/D159093
|
Revision tags: llvmorg-17.0.0-rc3 |
|
#
888717e8 |
| 09-Aug-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][transform] Enable gpu-to-nvvm via conversion patterns driven by TD
This revision untangles a few more conversion pieces and allows rewriting the relatively intricate (and somewhat inconsisten
[mlir][transform] Enable gpu-to-nvvm via conversion patterns driven by TD
This revision untangles a few more conversion pieces and allows rewriting the relatively intricate (and somewhat inconsistent) LowerGpuOpsToNVVMOpsPass in a declarative fashion that provides a much better understanding and control.
Differential Revision: https://reviews.llvm.org/D157617
show more ...
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
44e6318c |
| 24-Jul-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][transforms] Revamp the implementation of mapping loops to GPUs
This revision significantly simplifies the specification and implementation of mapping loops to GPU ids.
Each type of mapping (
[mlir][transforms] Revamp the implementation of mapping loops to GPUs
This revision significantly simplifies the specification and implementation of mapping loops to GPU ids.
Each type of mapping (block, warpgroup, warp, thread) now comes with 2 mapping modes: 1. a 3-D "grid-like" mode, subject to alignment considerations on threadIdx.x, on which predication may occur on a per-dimension 3-D sub-rectangle basis. 2. a n-D linearized mode, on which predication may only occur on a linear basis.
In the process, better size and alignment requirement inference are introduced along with improved runtime verification messages.
The `warp_dims` attribute was deemed confusing and is removed from the transform in favor of better size inference.
Differential Revision: https://reviews.llvm.org/D155941
show more ...
|
#
ff8775f3 |
| 23-Jul-2023 |
Quinn Dawkins <quinn@nod-labs.com> |
[mlir][GPU] Add op for unrolling contractions to a native size
Adds `apply_patterns.gpu.unroll_vectors_subgroup_mma` which allows specifying a native MMA shape of `m`, `n`, and `k` to unroll to, gre
[mlir][GPU] Add op for unrolling contractions to a native size
Adds `apply_patterns.gpu.unroll_vectors_subgroup_mma` which allows specifying a native MMA shape of `m`, `n`, and `k` to unroll to, greedily unrolling the inner most dimension of contractions and other vector operations based on expected usage.
Differential Revision: https://reviews.llvm.org/D156079
show more ...
|
#
90ecfa2a |
| 24-Jul-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][linalg] NFC - Move some utils in preparation for revamping mapping of scf.forall
|
#
9ab34689 |
| 07-Jul-2023 |
Alex Zinenko <zinenko@google.com> |
[mlir] add a simple gpu barrier elimination mechanism
GPU code generation, and specifically the shared memory copy insertion may introduce spurious barriers guarding read-after-read dependencies or
[mlir] add a simple gpu barrier elimination mechanism
GPU code generation, and specifically the shared memory copy insertion may introduce spurious barriers guarding read-after-read dependencies or read-after-write on non-aliasing data, which degrades performance due to unnecessary synchronization. Add a pattern and transform op that removes such barriers by analyzing memory effects that the barrier actually guards that are not also guarded by other barriers. The code is adapted from the Polygeist incubator project.
Co-authored-by: William Moses <gh@wsmoses.com> Co-authored-by: Ivan Radanov Ivanov <ivanov.i.aa@m.titech.ac.jp>
Reviewed By: nicolasvasilache, wsmoses
Differential Revision: https://reviews.llvm.org/D154720
show more ...
|
#
efc290ce |
| 22-Jun-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][affine] More efficient `makeComposedFolded...` helpers
The old code used to materialize constants as ops, immediately folded them into the resulting affine map and then deleted the constant o
[mlir][affine] More efficient `makeComposedFolded...` helpers
The old code used to materialize constants as ops, immediately folded them into the resulting affine map and then deleted the constant ops again. Instead, directly fold the attributes into the affine map. Furthermore, all helpers accept `OpFoldResult` instead of `Value` now. This makes the code at call sites more efficient, because it is no longer necessary to materialize a `Value`, just to be able to use these helper functions.
Note: The API has changed (accepts OpFoldResult instead of Value), otherwise this change is NFC.
Differential Revision: https://reviews.llvm.org/D153324
show more ...
|
#
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 |
|
#
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 |
|
#
6089d612 |
| 16-Apr-2023 |
Rahul Kayaith <rkayaith@gmail.com> |
[mlir] Prevent implicit downcasting to interfaces
Currently conversions to interfaces may happen implicitly (e.g. `Attribute -> TypedAttr`), failing a runtime assert if the interface isn't actually
[mlir] Prevent implicit downcasting to interfaces
Currently conversions to interfaces may happen implicitly (e.g. `Attribute -> TypedAttr`), failing a runtime assert if the interface isn't actually implemented. This change marks the `Interface(ValueT)` constructor as explicit so that a cast is required.
Where it was straightforward to I adjusted code to not require casts, otherwise I just made them explicit.
Depends on D148491, D148492
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D148493
show more ...
|
#
4c48f016 |
| 20-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][Affine][NFC] Wrap dialect in "affine" namespace
This cleanup aligns the affine dialect with all the other dialects.
Differential Revision: https://reviews.llvm.org/D148687
|
Revision tags: llvmorg-16.0.1 |
|
#
015cd84d |
| 20-Mar-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
Revert "[mlir][Linalg][Transform] Avoid FunctionalStyleTransformOpTrait where unnecesseary to improve usability"
This reverts commit 31aa8ea252c0b6acdcb362c1d0f01cc4b810d6d0.
This is currently not
Revert "[mlir][Linalg][Transform] Avoid FunctionalStyleTransformOpTrait where unnecesseary to improve usability"
This reverts commit 31aa8ea252c0b6acdcb362c1d0f01cc4b810d6d0.
This is currently not in a good state as we have some footguns due to missing listeners.
show more ...
|
#
ba7f3e1d |
| 20-Mar-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Transform] Fix support for mapping to GPU warps and to linear ids
c59465e1203dd78d06e15f7ddf62141807dbd5a7 introduced mapping to warps and linear GPU ids.
In the implementation, the delinear
[mlir][Transform] Fix support for mapping to GPU warps and to linear ids
c59465e1203dd78d06e15f7ddf62141807dbd5a7 introduced mapping to warps and linear GPU ids.
In the implementation, the delinearization basis is reversed from [x, y, z] to [z, y x] order to properly compute the strides and allow delinearization.
Prior to this commit, we forgot to reverse it back to [x, y, z] order before materializing the indices.
Fix this oversight.
show more ...
|
#
31aa8ea2 |
| 20-Mar-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Linalg][Transform] Avoid FunctionalStyleTransformOpTrait where unnecesseary to improve usability
Differential Revision: https://reviews.llvm.org/D146305
|
#
c59465e1 |
| 20-Mar-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Transform] Add support for mapping to GPU warps and to linear ids
This revisions refactors the implementation of mapping to threads to additionally allow warps and linear ids to be specified.
[mlir][Transform] Add support for mapping to GPU warps and to linear ids
This revisions refactors the implementation of mapping to threads to additionally allow warps and linear ids to be specified.
`warp_dims` is currently specified along with `block_dims` as a transform attribute.
Linear ids on th other hand use the flattened block_dims to predicate on the first (linearized) k threads. An additional GPULinearIdMappingAttr is added to the GPU dialect to allow specifying loops mapped to this new scheme.
Various implementation and transform op semantics cleanups are also applied.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D146130
show more ...
|
Revision tags: llvmorg-16.0.0 |
|
#
8bdf3878 |
| 15-Mar-2023 |
Kazu Hirata <kazu@google.com> |
Use *{Map,Set}::contains (NFC)
Differential Revision: https://reviews.llvm.org/D146104
|