summaryrefslogtreecommitdiff
path: root/mlir/lib/Rewrite/PatternApplicator.cpp
AgeCommit message (Collapse)Author
2025-08-21[MLIR] Adopt LDBG() debug macro in PatternApplicator.cpp (NFC) (#154724)Mehdi Amini
2025-08-01[MLIR] Migrate pattern application / dialect conversion to the LDBG logging ↵Mehdi Amini
format (#150991) This prefix the output with the DEBUG_TYPE. Dialect conversion is using a ScopedPrinter, we insert the raw_ldbg_ostream to consistently prefix each new line.
2025-07-17[mlir][core] Add an MLIR "pattern catalog" generator (#146228)Jeremy Kun
This PR adds a feature that attaches a listener to all RewritePatterns that logs information about the modified operations. When the MLIR test suite is run, these debug outputs can be filtered and combined into an index linking operations to the patterns that insert, modify, or replace them. This index is intended to be used to create a website that allows one to look up patterns from an operation name. The debug logs emitted can be viewed with --debug-only=generate-pattern-catalog, and the lit config is modified to do this when the env var MLIR_GENERATE_PATTERN_CATALOG is set. Example usage: ``` mkdir build && cd build cmake -G Ninja ../llvm \ -DLLVM_ENABLE_PROJECTS="mlir" \ -DLLVM_TARGETS_TO_BUILD="host" \ -DCMAKE_BUILD_TYPE=DEBUG ninja -j 24 check-mlir MLIR_GENERATE_PATTERN_CATALOG=1 bin/llvm-lit -j 24 -v -a tools/mlir/test | grep 'pattern-logging-listener' | sed 's/^# | [pattern-logging-listener] //g' | sort | uniq > pattern_catalog.txt ``` Sample pattern catalog output (that fits in a gist): https://gist.github.com/j2kun/02d1ab8d31c10d71027724984c89905a --------- Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com> Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
2025-05-22[mlir] Use llvm::stable_sort (NFC) (#141186)Kazu Hirata
2024-01-31[mlir] Fix debug output for passes that modify top-level operation. (#80022)Robert Konicar
Make it so that when the top-level (root) operation itself is being modified, it is also used as the root for debug output in PatternApplicator. Fix #80021
2024-01-03[mlir] Add config for PDL (#69927)Jacques Pienaar
Make it so that PDL in pattern rewrites can be optionally disabled. PDL is still enabled by default and not optional bazel. So this should be a NOP for most folks, while enabling other to disable. This only works with tests disabled. With tests enabled this still compiles but tests fail as there is no lit config to disable tests that depend on PDL rewrites yet.
2024-01-03Revert "[mlir] Add config for PDL (#69927)"max
This reverts commit 5930725c891b60f5fb94058c6c08a55a2e03d83e.
2024-01-03[mlir] Add config for PDL (#69927)Jacques Pienaar
Make it so that PDL in pattern rewrites can be optionally disabled. PDL is still enabled by default and not optional bazel. So this should be a NOP for most folks, while enabling other to disable. This is piped through mlir-tblgen invocation and that could be changed/avoided by splitting up the passes file instead. This only works with tests disabled. With tests enabled this still compiles but tests fail as there is no lit config to disable tests that depend on PDL rewrites yet.
2023-04-10Add tracing for pattern application in a ApplyPatternActionMehdi Amini
Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D144816
2022-11-08[mlir:PDL] Add support for DialectConversion with pattern configurationsRiver Riddle
Up until now PDL(L) has not supported dialect conversion because we had no way of remapping values or integrating with type conversions. This commit rectifies that by adding a new "pattern configuration" concept to PDL. This essentially allows for attaching external configurations to patterns, which can hook into pattern events (for now just the scope of a rewrite, but we could also pass configs to native rewrites as well). This allows for injecting the type converter into the conversion pattern rewriter. Differential Revision: https://reviews.llvm.org/D133142
2022-07-14[mlir] (NFC) run clang-format on all filesJeff Niu
2022-01-02Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)Mehdi Amini
2021-12-22Fix more clang-tidy cleanups in mlir/ (NFC)Mehdi Amini
2021-05-08[mlir] Debug print pattern before and after matchAndRewrite callButygin
Motivation: we have passes with lot of rewrites and when one one them segfaults or asserts, it is very hard to find waht exactly pattern failed without debug info. Differential Revision: https://reviews.llvm.org/D101443
2021-04-27[MLIR] Debug log IR after pattern applicationsFrederik Gossen
Like `print-ir-after-all` and `-before-all`, this allows to inspect IR for debug purposes. While the former allow to inspect only between passes, this change allows to follow the rewrites that happen within passes. Differential Revision: https://reviews.llvm.org/D100940
2021-03-23[mlir][Pattern] Add better support for using interfaces/traits to match root ↵River Riddle
operations in rewrite patterns To match an interface or trait, users currently have to use the `MatchAny` tag. This tag can be quite problematic for compile time for things like the canonicalizer, as the `MatchAny` patterns may get applied to *every* operation. This revision adds better support by bucketing interface/trait patterns based on which registered operations have them registered. This means that moving forward we will only attempt to match these patterns to operations that have this interface registered. Two simplify defining patterns that match traits and interfaces, two new utility classes have been added: OpTraitRewritePattern and OpInterfaceRewritePattern. Differential Revision: https://reviews.llvm.org/D98986
2021-03-22Rename FrozenRewritePatternList -> FrozenRewritePatternSet; NFC.Chris Lattner
This nicely aligns the naming with RewritePatternSet. This type isn't as widely used, but we keep a using declaration in to help with downstream consumption of this change. Differential Revision: https://reviews.llvm.org/D99131
2021-03-16[mlir][PDL] Add support for variadic operands and results in the PDL byte codeRiver Riddle
Supporting ranges in the byte code requires additional complexity, given that a range can't be easily representable as an opaque void *, as is possible with the existing bytecode value types (Attribute, Type, Value, etc.). To enable representing a range with void *, an auxillary storage is used for the actual range itself, with the pointer being passed around in the normal byte code memory. For type ranges, a TypeRange is stored. For value ranges, a ValueRange is stored. The above problem represents a majority of the complexity involved in this revision, the rest is adapting/adding byte code operations to support the changes made to the PDL interpreter in the parent revision. After this revision, PDL will have initial end-to-end support for variadic operands/results. Differential Revision: https://reviews.llvm.org/D95723
2020-12-01[mlir][PDL] Add support for PDL bytecode and expose PDL support to ↵River Riddle
OwningRewritePatternList PDL patterns are now supported via a new `PDLPatternModule` class. This class contains a ModuleOp with the pdl::PatternOp operations representing the patterns, as well as a collection of registered C++ functions for native constraints/creations/rewrites/etc. that may be invoked via the pdl patterns. Instances of this class are added to an OwningRewritePatternList in the same fashion as C++ RewritePatterns, i.e. via the `insert` method. The PDL bytecode is an in-memory representation of the PDL interpreter dialect that can be efficiently interpreted/executed. The representation of the bytecode boils down to a code array(for opcodes/memory locations/etc) and a memory buffer(for storing attributes/operations/values/any other data necessary). The bytecode operations are effectively a 1-1 mapping to the PDLInterp dialect operations, with a few exceptions in cases where the in-memory representation of the bytecode can be more efficient than the MLIR representation. For example, a generic `AreEqual` bytecode op can be used to represent AreEqualOp, CheckAttributeOp, and CheckTypeOp. The execution of the bytecode is split into two phases: matching and rewriting. When matching, all of the matched patterns are collected to avoid the overhead of re-running parts of the matcher. These matched patterns are then considered alongside the native C++ patterns, which rewrite immediately in-place via `RewritePattern::matchAndRewrite`, for the given root operation. When a PDL pattern is matched and has the highest benefit, it is passed back to the bytecode to execute its rewriter. Differential Revision: https://reviews.llvm.org/D89107
2020-10-26[mlir][Pattern] Add a new FrozenRewritePatternList classRiver Riddle
This class represents a rewrite pattern list that has been frozen, and thus immutable. This replaces the uses of OwningRewritePatternList in pattern driver related API, such as dialect conversion. When PDL becomes more prevalent, this API will allow for optimizing a set of patterns once without the need to do this per run of a pass. Differential Revision: https://reviews.llvm.org/D89104
2020-10-26[mlir][NFC] Move around the code related to PatternRewriting to improve layeringRiver Riddle
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those pieces to a better location such that they are easier to evolve in the future(e.g. with PDL). More concretely this revision does the following: * Create a Transforms/GreedyPatternRewriteDriver.h and move the apply*andFold methods there. The definitions for these methods are already in Transforms/ so it doesn't make sense for the declarations to be in IR. * Create a new lib/Rewrite library and move PatternApplicator there. This new library will be focused on applying rewrites, and will also include compiling rewrites with PDL. Differential Revision: https://reviews.llvm.org/D89103