#
75622e3f |
| 28-Jan-2025 |
Mehdi Amini <joker.eph@gmail.com> |
[MLIR] Define `getArgument()` for Toy tutorial passes
This is important during debugging to be able to dump a pass pipeline. It is also what is used by `--mlir-print-ir-tree-dir` to compute filename
[MLIR] Define `getArgument()` for Toy tutorial passes
This is important during debugging to be able to dump a pass pipeline. It is also what is used by `--mlir-print-ir-tree-dir` to compute filenames during dumps.
show more ...
|
#
db791b27 |
| 02-Jul-2024 |
Ramkumar Ramachandra <ramkumar.ramachandra@codasip.com> |
mlir/LogicalResult: move into llvm (#97309)
This patch is part of a project to move the Presburger library into
LLVM.
|
#
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.
|
#
5fcf907b |
| 17-Jan-2024 |
Matthias Springer <me@m-sp.org> |
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260)
This commit renames 4 pattern rewriter API functions:
* `updateRootInPlace` -> `modifyOpInPlace`
* `startRootUpdate` -> `sta
[mlir][IR] Rename "update root" to "modify op" in rewriter API (#78260)
This commit renames 4 pattern rewriter API functions:
* `updateRootInPlace` -> `modifyOpInPlace`
* `startRootUpdate` -> `startOpModification`
* `finalizeRootUpdate` -> `finalizeOpModification`
* `cancelRootUpdate` -> `cancelOpModification`
The term "root" is a misnomer. The root is the op that a rewrite pattern
matches against
(https://mlir.llvm.org/docs/PatternRewriter/#root-operation-name-optional).
A rewriter must be notified of all in-place op modifications, not just
in-place modifications of the root
(https://mlir.llvm.org/docs/PatternRewriter/#pattern-rewriter). The old
function names were confusing and have contributed to various broken
rewrite patterns.
Note: The new function names use the term "modify" instead of "update"
for consistency with the `RewriterBase::Listener` terminology
(`notifyOperationModified`).
show more ...
|
#
ec6da065 |
| 20-Oct-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for misc-include-cleaner in MLIR examples
|
#
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 ...
|
#
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
|
#
2443d946 |
| 06-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir] Use RankedTensorType when rank is required
`RankedTensorOf` and `TensorRankOf` (in Tablegen files) now generate code that uses `RankedTensorType` instead of `TensorType`. This gives us more a
[mlir] Use RankedTensorType when rank is required
`RankedTensorOf` and `TensorRankOf` (in Tablegen files) now generate code that uses `RankedTensorType` instead of `TensorType`. This gives us more accurate type information (e.g., when calling `op.getType()`).
Also use restrict tensor.expand_shape/tensor.collapse_shape/tensor.pad to ranked tensors. Only cast ops should deal with unranked tensors.
Also improves a few places in the code base (e.g., Toy tutorial) where a ranked tensor is assumed (e.g., because `getRank` is called) but a `TensorType` is currently used: cast to `RankedTensorType` directly, so that the assertion is triggered directly at the cast.
Differential Revision: https://reviews.llvm.org/D147149
show more ...
|
#
984b800a |
| 09-Jan-2023 |
serge-sans-paille <sguelton@mozilla.com> |
Move from llvm::makeArrayRef to ArrayRef deduction guides - last part
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files.
Differential Re
Move from llvm::makeArrayRef to ArrayRef deduction guides - last part
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
show more ...
|
#
abc362a1 |
| 29-Sep-2022 |
Jakub Kuderski <kubak@google.com> |
[mlir][arith] Change dialect name from Arithmetic to Arith
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.
Tested with: `ninja check-mlir check-ml
[mlir][arith] Change dialect name from Arithmetic to Arith
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.
Tested with: `ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples`
and `bazel build --config=generic_clang @llvm-project//mlir:all`.
Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini
Differential Revision: https://reviews.llvm.org/D134762
show more ...
|
#
b7f93c28 |
| 14-Jul-2022 |
Jeff Niu <jeff@modular.com> |
[mlir] (NFC) run clang-format on all files
|
#
58ceae95 |
| 18-Apr-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace
FuncOp has been moved to the `func` namespace for a little over a month, the using directive can be dropped now.
|
#
5e50dd04 |
| 31-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Rework the implementation of TypeID
This commit restructures how TypeID is implemented to ideally avoid the current problems related to shared libraries. This is done by changing the "implici
[mlir] Rework the implementation of TypeID
This commit restructures how TypeID is implemented to ideally avoid the current problems related to shared libraries. This is done by changing the "implicit" fallback path to use the name of the type, instead of using a static template variable (which breaks shared libraries). The major downside to this is that it adds some additional initialization costs for the implicit path. Given the use of type names for uniqueness in the fallback, we also no longer allow types defined in anonymous namespaces to have an implicit TypeID. To simplify defining an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro was added to allow for explicitly defining a TypeID directly on an internal class.
To help identify when types are using the fallback, `-debug-only=typeid` can be used to log which types are using implicit ids.
This change generally only requires changes to the test passes, which are all defined in anonymous namespaces, and thus can't use the fallback any longer.
Differential Revision: https://reviews.llvm.org/D122775
show more ...
|
#
4a3460a7 |
| 16-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"
This removes any potential confusion with the `getType` accessors which correspond to SSA results of an operation, and makes
[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"
This removes any potential confusion with the `getType` accessors which correspond to SSA results of an operation, and makes it clear what the intent is (i.e. to represent the type of the function).
Differential Revision: https://reviews.llvm.org/D121762
show more ...
|
#
ccfcfa94 |
| 15-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Toy][NFC] Switch toy to use prefixed accessors
|
#
ee2c6cd9 |
| 09-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][toy] Define a FuncOp operation in toy and drop the dependence on FuncOp
FuncOp is being moved out of the builtin dialect, and defining a custom toy operation showcases various aspects of defi
[mlir][toy] Define a FuncOp operation in toy and drop the dependence on FuncOp
FuncOp is being moved out of the builtin dialect, and defining a custom toy operation showcases various aspects of defining function-like operation (e.g. inlining, passes, etc.).
Differential Revision: https://reviews.llvm.org/D121264
show more ...
|
#
23aa5a74 |
| 26-Feb-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the initial renaming (which by itself is already huge), but there are a large number of cleanups unlocked/necessary afterwards:
* Removing a bunch of unnecessary dependencies on Func * Cleaning up the From/ToStandard conversion passes * Preparing for the move of FuncOp to the Func dialect
See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061
Differential Revision: https://reviews.llvm.org/D120624
show more ...
|
#
41574554 |
| 04-Jan-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>
The only benefit of FunctionPass is that it filters out function declarations. This isn't enough to justify carrying it around,
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>
The only benefit of FunctionPass is that it filters out function declarations. This isn't enough to justify carrying it around, as we can simplify filter out declarations when necessary within the pass. We can also explore with better scheduling primitives to filter out declarations at the pipeline level in the future.
The definition of FunctionPass is left intact for now to allow time for downstream users to migrate.
Differential Revision: https://reviews.llvm.org/D117182
show more ...
|
#
be0a7e9f |
| 07-Dec-2021 |
Mehdi Amini <joker.eph@gmail.com> |
Adjust "end namespace" comment in MLIR to match new agree'd coding style
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html
Differenti
Adjust "end namespace" comment in MLIR to match new agree'd coding style
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html
Differential Revision: https://reviews.llvm.org/D115309
show more ...
|
#
015192c6 |
| 27-Oct-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir:DialectConversion] Restructure how argument/target materializations get invoked
The current implementation invokes materializations whenever an input operand does not have a mapping for the de
[mlir:DialectConversion] Restructure how argument/target materializations get invoked
The current implementation invokes materializations whenever an input operand does not have a mapping for the desired type, i.e. it requires materialization at the earliest possible point. This conflicts with goal of dialect conversion (and also the current documentation) which states that a materialization is only required if the materialization is supposed to persist after the conversion process has finished.
This revision refactors this such that whenever a target materialization "might" be necessary, we insert an unrealized_conversion_cast to act as a temporary materialization. This allows for deferring the invocation of the user materialization hooks until the end of the conversion process, where we actually have a better sense if it's actually necessary. This has several benefits:
* In some cases a target materialization hook is no longer necessary When performing a full conversion, there are some situations where a temporary materialization is necessary. Moving forward, these users won't need to provide any target materializations, as the temporary materializations do not require the user to provide materialization hooks.
* getRemappedValue can now handle values that haven't been converted yet Before this commit, it wasn't well supported to get the remapped value of a value that hadn't been converted yet (making it difficult/impossible to convert multiple operations in many situations). This commit updates getRemappedValue to properly handle this case by inserting temporary materializations when necessary.
Another code-health related benefit is that with this change we can move a majority of the complexity related to materializations to the end of the conversion process, instead of handling adhoc while conversion is happening.
Differential Revision: https://reviews.llvm.org/D111620
show more ...
|
#
a54f4eae |
| 12-Oct-2021 |
Mogball <jeffniu22@gmail.com> |
[MLIR] Replace std ops with arith dialect ops
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects.
Renamed
[MLIR] Replace std ops with arith dialect ops
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects.
Renamed all instances of operations in the codebase and in tests.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D110797
show more ...
|
#
0cb5d7fc |
| 21-Sep-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add value_begin/value_end methods to DenseElementsAttr
Currently DenseElementsAttr only exposes the ability to get the full range of values for a given type T, but there are many situations w
[mlir] Add value_begin/value_end methods to DenseElementsAttr
Currently DenseElementsAttr only exposes the ability to get the full range of values for a given type T, but there are many situations where we just want the beginning/end iterator. This revision adds proper value_begin/value_end methods for all of the supported T types, and also cleans up a bit of the interface.
Differential Revision: https://reviews.llvm.org/D104173
show more ...
|
#
dc4e913b |
| 22-Mar-2021 |
Chris Lattner <clattner@nondot.org> |
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these names to use t
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these names to use the new preferred names. We'll keep the old names around for a couple weeks to help transitions.
Differential Revision: https://reviews.llvm.org/D99127
show more ...
|
#
113baa2b |
| 21-Mar-2021 |
Jacques Pienaar <jpienaar@google.com> |
Update examples post OwningRewritePatternList change
|
#
e2310704 |
| 10-Feb-2021 |
Julian Gross <julian.gross@dfki.de> |
[MLIR] Create memref dialect and move dialect-specific ops from std.
Create the memref dialect and move dialect-specific ops from std dialect to this dialect.
Moved ops: AllocOp -> MemRef_AllocOp A
[MLIR] Create memref dialect and move dialect-specific ops from std.
Create the memref dialect and move dialect-specific ops from std dialect to this dialect.
Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp AssumeAlignmentOp -> MemRef_AssumeAlignmentOp DeallocOp -> MemRef_DeallocOp DimOp -> MemRef_DimOp MemRefCastOp -> MemRef_CastOp MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp LoadOp -> MemRef_LoadOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp SubViewOp -> MemRef_SubViewOp TransposeOp -> MemRef_TransposeOp TensorLoadOp -> MemRef_TensorLoadOp TensorStoreOp -> MemRef_TensorStoreOp TensorToMemRefOp -> MemRef_BufferCastOp ViewOp -> MemRef_ViewOp
The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667
Differential Revision: https://reviews.llvm.org/D98041
show more ...
|