summaryrefslogtreecommitdiff
path: root/mlir/lib/Tools/PDLL/CodeGen
AgeCommit message (Collapse)Author
2025-10-16[mlir] Replace LLVM_ATTRIBUTE_UNUSED with [[maybe_unused]] (NFC) (#163703)Kazu Hirata
This patch replaces LLVM_ATTRIBUTE_UNUSED with [[maybe_unused]], introduced as part of C++17.
2025-07-22[mlir][NFC] update `mlir/lib` create APIs (26/n) (#149933)Maksim Levental
See https://github.com/llvm/llvm-project/pull/147168 for more info. --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2025-07-15[mlir] Remove unused includes (NFC) (#148872)Kazu Hirata
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-06-25[mlir] Migrate away from std::nullopt (NFC) (#145523)Kazu Hirata
ArrayRef has a constructor that accepts std::nullopt. This constructor dates back to the days when we still had llvm::Optional. Since the use of std::nullopt outside the context of std::optional is kind of abuse and not intuitive to new comers, I would like to move away from the constructor and eventually remove it. This patch migrates away from std::nullopt in favor of ArrayRef<T>() where we use perfect forwarding. Note that {} would be ambiguous for perfect forwarding to work.
2025-03-17[mlir] Use `getSingleElement`/`hasSingleElement` in various places (#131460)Matthias Springer
This is a code cleanup. Update a few places in MLIR that should use `hasSingleElement`/`getSingleElement`. Note: `hasSingleElement` is faster than `.getSize() == 1` when it is used with linked lists etc. Depends on #131508.
2024-07-02mlir/LogicalResult: move into llvm (#97309)Ramkumar Ramachandra
This patch is part of a project to move the Presburger library into LLVM.
2024-04-30[mlir][NFC] update code to use `mlir::dyn_cast/cast/isa` (#90633)Peiming Liu
Fix compiler warning caused by using deprecated interface (https://github.com/llvm/llvm-project/pull/90413)
2023-09-01[MLIR][PDL] Add PDLL support for negated native constraintsMogball
This commit enables the expression of negated native constraints in PDLL: If a constraint is prefixed with "not" it is parsed as a negated constraint and hence the attribute `isNegated` of the emitted `pdl.apply_native_constraint` operation is set to `true`. In first instance this is only supported for the calling of external native C++ constraints and generation of PDL patterns. Previously, negating a native constraint would have been handled by creating an additional native call, e.g. ```PDLL Constraint checkA(input: Attr); Constarint checkNotA(input: Attr); ``` or by including an explicit additional operand for negation, e.g. `Constraint checkA(input: Attr, negated: Attr);` With this a constraint can simply be negated by prefixing it with `not`. e.g. ```PDLL Constraint simpleConstraint(op: Op); Pattern example { let inputOp = op<test.bar>() ->(type: Type); let root = op<test.foo>(inputOp.0) -> (); not simpleConstraint(inputOp); simpleConstraint(root); erase root; } ``` Depends on [[ https://reviews.llvm.org/D153871 | D153871 ]] Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D153959
2023-05-12[mlir] Move casting calls from methods to function callsTres Popp
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
2023-01-14[mlir] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata
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
2023-01-13[mlir] Add #include <optional> (NFC)Kazu Hirata
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
2022-12-17mlir/tblgen: use std::optional in generationRamkumar Ramachandra
This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-03[mlir] Use std::nullopt instead of None (NFC)Kazu Hirata
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
2022-11-08[mlir:PDLL] Add support for building a range from a tuple within a rewriteRiver Riddle
This allows for constructing type and value ranges from various sub elements, which makes it easier to construct operations that take a range as an operand or result type. Range construction is currently limited to within rewrites, to match the current constraint on the PDL side. Differential Revision: https://reviews.llvm.org/D133720
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-09-30[mlir:PDL][NFC] Update PDL API to use prefixed accessorsRiver Riddle
This doesn't flip the switch for prefix generation yet, that'll be done in a followup.
2022-09-21[mlir] Flip PDL to use Both accessorsRiver Riddle
This allows for incrementally updating the old API usages without needing to update everything at once. PDL will be left on Both for a little bit and then flipped to prefixed when all APIs have been updated. Differential Revision: https://reviews.llvm.org/D134387
2022-07-25[mlir] Refactor the Parser library in preparation for an MLIR binary formatRiver Riddle
The current Parser library is solely focused on providing API for the textual MLIR format, but MLIR will soon also provide a binary format. This commit renames the current Parser library to AsmParser to better correspond to what the library is actually intended for. A new Parser library is added which will act as a unified parser interface between both text and binary formats. Most parser clients are unaffected, given that the unified interface is essentially the same as the current interface. Only clients that rely on utilizing the AsmParserState, or those that want to parse Attributes/Types need to be updated to point to the AsmParser library. Differential Revision: https://reviews.llvm.org/D129605
2022-06-13[mlir] (NFC) Clean up bazel and CMake target namesMogball
All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect.
2022-05-30[mlir:PDLL] Rework the C++ generation of native Constraint/Rewrite arguments ↵River Riddle
and results The current translation uses the old "ugly"/"raw" form which used PDLValue for the arguments and results. This commit updates the C++ generation to use the recently added sugar that allows for directly using the desired types for the arguments and result of PDL functions. In addition, this commit also properly imports the C++ class for ODS operations, constraints, and interfaces. This allows for a much more convienent C++ API than previously granted with the raw/low-level types. Differential Revision: https://reviews.llvm.org/D124817
2022-05-25[mlir][PDLL] Allow numeric result indexing for unregistered opChia-hung Duan
If we don't specify the result index while matching operand with the result of certain operation, it's supposed to match all the results of the operation with the operand. For registered op, it's easy to do that by either indexing with number or name. For unregistered op, this commit enables the numeric result indexing for this use case. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D126330
2022-04-06[mlir:PDL] Expand how native constraint/rewrite functions can be definedRiver Riddle
This commit refactors the expected form of native constraint and rewrite functions, and greatly reduces the necessary user complexity required when defining a native function. Namely, this commit adds in automatic processing of the necessary PDLValue glue code, and allows for users to define constraint/rewrite functions using the C++ types that they actually want to use. As an example, lets see a simple example rewrite defined today: ``` static void rewriteFn(PatternRewriter &rewriter, PDLResultList &results, ArrayRef<PDLValue> args) { ValueRange operandValues = args[0].cast<ValueRange>(); TypeRange typeValues = args[1].cast<TypeRange>(); ... // Create an operation at some point and pass it back to PDL. Operation *op = rewriter.create<SomeOp>(...); results.push_back(op); } ``` After this commit, that same rewrite could be defined as: ``` static Operation *rewriteFn(PatternRewriter &rewriter ValueRange operandValues, TypeRange typeValues) { ... // Create an operation at some point and pass it back to PDL. return rewriter.create<SomeOp>(...); } ``` Differential Revision: https://reviews.llvm.org/D122086
2022-03-19[mlir:PDLL][NFC] Remove a dead comment about constant paramsRiver Riddle
These were removed, and the FIXME is no longer relevant.
2022-03-19[mlir:PDL] Remove the ConstantParams support from native Constraints/RewritesRiver Riddle
This support has never really worked well, and is incredibly clunky to use (it effectively creates two argument APIs), and clunky to generate (it isn't clear how we should actually expose this from PDL frontends). Treating these as just attribute arguments is much much cleaner in every aspect of the stack. If we need to optimize lots of constant parameters, it would be better to investigate internal representation optimizations (e.g. batch attribute creation), that do not affect the user (we want a clean external API). Differential Revision: https://reviews.llvm.org/D121569
2022-03-07[mlir][NFC] Move Parser.h to Parser/River Riddle
There is no reason for this file to be at the top-level, and its current placement predates the Parser/ folder's existence. Differential Revision: https://reviews.llvm.org/D121024
2022-03-03[PDLL] Add support for tablegen includes and importing ODS informationRiver Riddle
This commit adds support for processing tablegen include files, and importing various information from ODS. This includes operations, attribute+type constraints, attribute/operation/type interfaces, etc. This will allow for much more robust tooling, and also allows for referencing ODS constructs directly within PDLL (imported interfaces can be used as constraints, operation result names can be used for member access, etc). Differential Revision: https://reviews.llvm.org/D119900
2022-02-28Add explicit `this->` to access method in attempt to fix gcc5 build (NFC)Mehdi Amini
2022-02-27Add explicit capture for `this` pointer in attempt to fix gcc5 build (NFC)Mehdi Amini
2022-02-26[mlir:PDLL] Add support for C++ generationRiver Riddle
This commits adds a C++ generator to PDLL that generates wrapper PDL patterns directly usable in C++ code, and also generates the definitions of native constraints/rewrites that have code bodies specified in PDLL. This generator is effectively the PDLL equivalent of the current DRR generator, and will allow easy replacement of DRR patterns with PDLL patterns. A followup will start to utilize this for end-to-end integration testing and show case how to use this as a drop-in replacement for DRR tablegen usage. Differential Revision: https://reviews.llvm.org/D119781
2022-02-26[mlir:PDLL] Add support for PDL MLIR code generationRiver Riddle
This commits starts to plumb PDLL down into MLIR and adds an initial PDL generator. After this commit, we will have conceptually support end-to-end execution of PDLL. Followups will add CPP generation to match the current DRR setup, and begin to add various end-to-end tests to test PDLL execution. Differential Revision: https://reviews.llvm.org/D119779