summaryrefslogtreecommitdiff
path: root/mlir/lib/TableGen/Predicate.cpp
AgeCommit message (Collapse)Author
2025-07-02[mlir] Remove unused includes (NFC) (#146709)Kazu Hirata
2025-05-13[mlir] Use std::string::find with std::string_view (NFC) (#139683)Kazu Hirata
Starting with C++17, std::string::find accepts anything that can be converted to std::string_view, including StringRef, allowing us to avoid creating temporary instances of std::string.
2024-12-18[mlir] Add predicates to tablegen-defined properties (#120176)Krzysztof Drewniak
Give the properties from tablegen a `predicate` field that holds the predicate that the property needs to satisfy, if one exists, and hook that field up to verifier generation.
2024-10-18[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#112456)Rahul Joshi
Eliminate `llvm::` namespace qualifier for commonly used types in MLIR TableGen backends to reduce code clutter.
2024-10-01[TableGen] Change `getValueAsListOfDefs` to return const pointer vector ↵Rahul Joshi
(#110713) Change `getValueAsListOfDefs` to return a vector of const Record pointer, and remove `getValueAsListOfConstDefs` that was added as a transition aid. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
2024-10-01[MLIR][TableGen] Change MLIR TableGen to use const Record * (#110687)Rahul Joshi
This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
2024-09-15[mlir] Reland 5a6e52d6ef96d2bcab6dc50bdb369662ff17d2a0 with update (NFC)JOE1994
Excluded updates to mlir/lib/AsmParser/Parser.cpp , which caused LIT failure "FAIL: MLIR::completion.test" on multiple buildbots.
2024-09-15Revert "[mlir] Nits on uses of llvm::raw_string_ostream (NFC)"JOE1994
This reverts commit 5a6e52d6ef96d2bcab6dc50bdb369662ff17d2a0. "FAIL: MLIR::completion.test" on multiple buildbots.
2024-09-15[mlir] Nits on uses of llvm::raw_string_ostream (NFC)JOE1994
* Strip calls to raw_string_ostream::flush(), which is essentially a no-op * Strip unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
2022-09-17[mlir] Don't include SetVector.h (NFC)Kazu Hirata
2022-01-26[mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.hRiver Riddle
These are used pervasively during parsing. Differential Revision: https://reviews.llvm.org/D118291
2022-01-21[llvm] Cleanup header dependencies in ADT and Supportserge-sans-paille
The cleanup was manual, but assisted by "include-what-you-use". It consists in 1. Removing unused forward declaration. No impact expected. 2. Removing unused headers in .cpp files. No impact expected. 3. Removing unused headers in .h files. This removes implicit dependencies and is generally considered a good thing, but this may break downstream builds. I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the modification in the second part of the commit. 4. Replacing header inclusion by forward declaration. This has the same impact as 3. Notable changes: - llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h - llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h - llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h - llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h You may need to add some of these headers in your compilation units, if needs be. As an hint to the impact of the cleanup, running clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l before: 8000919 lines after: 7917500 lines Reduced dependencies also helps incremental rebuilds and is more ccache friendly, something not shown by the above metric :-) Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
2022-01-14Apply clang-tidy fixes for modernize-use-default-member-init to MLIR (NFC)Mehdi Amini
2022-01-02Apply clang-tidy fixes for readability-const-return-type to MLIR (NFC)Mehdi Amini
Reviewed By: rriddle, Mogball Differential Revision: https://reviews.llvm.org/D116251
2022-01-02Apply clang-tidy fixes for performance-unnecessary-value-param to MLIR (NFC)Mehdi Amini
Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D116250
2021-12-20Fix clang-tidy issues in mlir/ (NFC)Mehdi Amini
Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D115956
2021-12-08Adjust "end namespace" comment in MLIR to match new agree'd coding styleMehdi Amini
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
2021-03-16[mlir][PDL] Add support for variadic operands and results in the PDL InterpreterRiver Riddle
This revision extends the PDL Interpreter dialect to add support for variadic operands and results, with ranges of these values represented via the recently added !pdl.range type. To support this extension, three new operations have been added that closely match the single variant: * pdl_interp.check_types : Compare a range of types with a known range. * pdl_interp.create_types : Create a constant range of types. * pdl_interp.get_operands : Get a range of operands from an operation. * pdl_interp.get_results : Get a range of results from an operation. * pdl_interp.switch_types : Switch on a range of types. This revision handles adding support in the interpreter dialect and the conversion from PDL to PDLInterp. Support for variadic operands and results in the bytecode will be added in a followup revision. Differential Revision: https://reviews.llvm.org/D95722
2020-10-08Import llvm::StringSwitch into mlir namespace.Christian Sigg
Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D88971
2020-08-12[MLIR][NFC] Remove tblgen:: prefix in TableGen/*.cpp filesRahul Joshi
- Add "using namespace mlir::tblgen" in several of the TableGen/*.cpp files and eliminate the tblgen::prefix to reduce code clutter. Differential Revision: https://reviews.llvm.org/D85800
2020-07-07[mlir][NFC] Remove usernames and google bug numbers from TODO comments.River Riddle
These were largely leftover from when MLIR was a google project, and don't really follow LLVM guidelines.
2020-02-06[mlir-tblgen] Stop leaking PredNodesBenjamin Kramer
Technically a leak in tblgen is harmless, but this makes asan builds of mlir very noisy. Just use a SpecificBumpPtrAllocator that knows how to clean up after itself.
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-26Mass update the MLIR license header to mention "Part of the LLVM project"Mehdi Amini
This is an artifact from merging MLIR into LLVM, the file headers are now aligned with the rest of the project.
2019-12-23Adjust License.txt file to use the LLVM licenseMehdi Amini
PiperOrigin-RevId: 286906740
2019-10-20Fix minor spelling tweaks (NFC)Kazuaki Ishizaki
Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
2019-04-05 [TableGen] Support array attribute subclasses and constraintsLei Zhang
To support automatically constraint composition of ArrayAttr, a new predicate combiner, Concat, is introduced. It prepends a prefix and appends a postfix to a child predicate's final predicate string. -- PiperOrigin-RevId: 242121186
2019-03-29[TableGen] Consolidate constraint related conceptsLei Zhang
Previously we have multiple mechanisms to specify op definition and match constraints: TypeConstraint, AttributeConstraint, Type, Attr, mAttr, mAttrAnyOf, mPat. These variants are not added because there are so many distinct cases we need to model; essentially, they are all carrying a predicate. It's just an artifact of implementation. It's quite confusing for users to grasp these variants and choose among them. Instead, as the OpBase TableGen file, we need to strike to provide an unified mechanism. Each dialect has the flexibility to define its own aliases if wanted. This CL removes mAttr, mAttrAnyOf, mPat. A new base class, Constraint, is added. Now TypeConstraint and AttrConstraint derive from Constraint. Type and Attr further derive from TypeConstraint and AttrConstraint, respectively. Comments are revised and examples are added to make it clear how to use constraints. PiperOrigin-RevId: 240125076
2019-03-29[TableGen] Fix infinite loop in SubstLeaves substitutionLei Zhang
Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
2019-03-29TableGen: implement predicate tree and basic simplificationAlex Zinenko
A recent change in TableGen definitions allowed arbitrary AND/OR predicate compositions at the cost of removing known-true predicate simplification. Introduce a more advanced simplification mechanism instead. In particular, instead of folding predicate C++ expressions directly in TableGen, keep them as is and build a predicate tree in TableGen C++ library. The predicate expression-substitution mechanism, necessary to implement complex predicates for nested classes such as `ContainerType`, is replaced by a dedicated predicate. This predicate appears in the predicate tree and can be used for tree matching and separation. More specifically, subtrees defined below such predicate may be subject to different transformations than those that appear above. For example, a subtree known to be true above the substitution predicate is not necessarily true below it. Use the predicate tree structure to eliminate known-true and known-false predicates before code emission, as well as to collapse AND and OR predicates if their value can be deduced based on the value of one child. PiperOrigin-RevId: 229605997
2019-03-29TableGen: extract TypeConstraints from TypeAlex Zinenko
MLIR has support for type-polymorphic instructions, i.e. instructions that may take arguments of different types. For example, standard arithmetic operands take scalars, vectors or tensors. In order to express such instructions in TableGen, we need to be able to verify that a type object satisfies certain constraints, but we don't need to construct an instance of this type. The existing TableGen definition of Type requires both. Extract out a TypeConstraint TableGen class to define restrictions on types. Define the Type TableGen class as a subclass of TypeConstraint for consistency. Accept records of the TypeConstraint class instead of the Type class as values in the Arguments class when defining operators. Replace the predicate logic TableGen class based on conjunctive normal form with the predicate logic classes allowing for abitrary combinations of predicates using Boolean operators (AND/OR/NOT). The combination is implemented using simple string rewriting of C++ expressions and, therefore, respects the short-circuit evaluation order. No logic simplification is performed at the TableGen level so all expressions must be valid C++. Maintaining CNF using TableGen only would have been complicated when one needed to introduce top-level disjunction. It is also unclear if it could lead to a significantly simpler emitted C++ code. In the future, we may replace inplace predicate string combination with a tree structure that can be simplified in TableGen's C++ driver. Combined, these changes allow one to express traits like ArgumentsAreFloatLike directly in TableGen instead of relying on C++ trait classes. PiperOrigin-RevId: 229398247
2019-03-29Avoid redundant predicate checking in type matching.Jacques Pienaar
Expand type matcher template generator to consider a set of predicates that are known to hold. This avoids inserting redundant checking for trivially true predicates (for example predicate that hold according to the op definition). This only targets predicates that trivially holds and does not attempt any logic equivalence proof. PiperOrigin-RevId: 228880468
2019-03-29Put Operator and PredCNF into the tblgen namespaceLei Zhang
PiperOrigin-RevId: 228429130
2019-03-29Add tblgen::Type to wrap around TableGen Type defsLei Zhang
This CL added a tblgen::Type class to wrap around raw TableGen Record getValue*() calls on Type defs, which will provide a nicer API for handling TableGen Record. The PredCNF class is also updated to work together with tblgen::Type. PiperOrigin-RevId: 228429090
2019-03-29Verify type of operands match those specifed in op registry.Jacques Pienaar
Expand type to include matcher predicates. Use CNF form to allow specifying combinations of constraints for type. The matching call for the type is used to verify the construction of the operation as well as in rewrite pattern generation. The matching initially includes redundant checks (e.g., even if the operand of the op is guaranteed to satisfy some requirement, it is still checked during matcher generation for now). As well as some of the traits specified now check what the generated code already checks. Some of the traits can be removed in future as the verify method will include the relevant checks based on the op definition already. More work is needed for variadic operands. CNF form is used so that in the follow up redundant checks in the rewrite patterns could be omitted (e.g., when matching a F32Tensor, one does not need to verify that op X's operand 0 is a Tensor if that is guaranteed by op X's definition). The alternative was to have single matcher function specified, but this would not allow for reasoning about what attributes already hold (at the level of PredAtoms). Use this new operand type restrictions to rewrite BiasAdd with floating point operands as declarative pattern. PiperOrigin-RevId: 227991412