#
e8137503 |
| 03-Oct-2024 |
Rahul Joshi <rjoshi@nvidia.com> |
[NFC] Rename variable `recordKeeper` to `records` (#110989)
|
#
bccd37f6 |
| 02-Oct-2024 |
Rahul Joshi <rjoshi@nvidia.com> |
[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#110841)
Eliminate `llvm::` namespace qualifier for commonly used types in MLIR
TableGen backends to reduce code clutter.
|
#
b60c6cbc |
| 07-Sep-2024 |
Rahul Joshi <rjoshi@nvidia.com> |
[MLIR][TableGen] Migrate MLIR backends to use const RecordKeeper (#107505)
- Migrate MLIR backends to use a const RecordKeeper reference.
|
#
16df489f |
| 06-Sep-2024 |
Rahul Joshi <rjoshi@nvidia.com> |
[TableGen] Add const variants of accessors for backend (#106658)
Split RecordKeeper `getAllDerivedDefinitions` family of functions into
two variants:
(a) non-const ones that return vectors of `R
[TableGen] Add const variants of accessors for backend (#106658)
Split RecordKeeper `getAllDerivedDefinitions` family of functions into
two variants:
(a) non-const ones that return vectors of `Record *` and
(b) const ones, that return vector/ArrayRef of `const Record *`.
This will help gradual migration of TableGen backends to use
`const RecordKeeper` and by implication change code to work
with const pointers and better const correctness.
Existing backends are not yet compatible with the const family of
functions, so change them to use a non-constant `RecordKeeper`
reference, till they are migrated.
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.
|
#
39c739ee |
| 18-Mar-2024 |
Andrei Golubev <andrey.golubev@intel.com> |
[mlir][OpInterfacesGen][NFC] Add newline after traits declaration (#85633)
Slightly improve the readability of the tablegen-generated code.
Co-authored-by: Orest Chura <orest.chura@intel.com>
|
#
cedeb31e |
| 12-Sep-2023 |
Markus Böck <markus.boeck02@gmail.com> |
[mlir] Support null interface to base conversion (#65988)
The current implicit conversion operator from an interface to a "base
interface" of the interface unconditionally calls `this->getImpl()`
[mlir] Support null interface to base conversion (#65988)
The current implicit conversion operator from an interface to a "base
interface" of the interface unconditionally calls `this->getImpl()`
which leads to accessing a null pointer if the interface instance is a
null instance.
This PR changes the ODS generated interface instance to explicitly check
and then return a null interface instance if the `this` instance is a
null instance.
show more ...
|
#
d01f559c |
| 08-Sep-2023 |
Jakub Kuderski <jakub@nod-labs.com> |
[mlir] Fix c++20 compat warning. NFC. (#65801)
`concept` is a c++20 keyword and makes some buildbots fail:
https://lab.llvm.org/buildbot/#/builders/160/builds/24345
|
#
edae8f6c |
| 07-Sep-2023 |
Markus Böck <markus.boeck02@gmail.com> |
[mlir] Make `classof` substitution in interface use an instance (#65492)
The substitution supported by `extraClassOf` is currently limited to
only the base instance, i.e. `Operation*`, `Type` or `A
[mlir] Make `classof` substitution in interface use an instance (#65492)
The substitution supported by `extraClassOf` is currently limited to
only the base instance, i.e. `Operation*`, `Type` or `Attribute`, which
limits the kind of checks you can perform in the `classof`
implementation.
Since prior to the user code, the interface concept is fetched, we can
use it to construct an instance of the interface, allowing use of its
methods in the `classof` check.
Since an instance of the interface allows access to the base class
methods through the `->` operator, I've gone ahead and replaced the
substitution of `$_op/$_type/$_attr` with an interface instance. This is
also consistent with `extraSharedClassDeclaration` and other methods
created in the interface class which do the same.
show more ...
|
#
6de63b82 |
| 25-May-2023 |
Tres Popp <tpopp@google.com> |
[mlir] Move tblgen code generation to use functional forms of cast/isa
Summary: The method forms are deprecated. This updates the rest of the tblgen uses of methods where a function call is availabl
[mlir] Move tblgen code generation to use functional forms of cast/isa
Summary: The method forms are deprecated. This updates the rest of the tblgen uses of methods where a function call is available.
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
Reviewers: rriddle
show more ...
|
#
5f036799 |
| 07-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][tblgen] Emit interface decls in definition order in the .td file
Interface decls were previously sorted by name. This lead to problems when using interface inheritance when both interfaces ar
[mlir][tblgen] Emit interface decls in definition order in the .td file
Interface decls were previously sorted by name. This lead to problems when using interface inheritance when both interfaces are defined in the same .td file. The derived interface must appear after the base interface, otherwise the generated C++ will not compile.
With this change, interfaces will compile as long as the base interface is defined before derived interfaces in the .td file.
Differential Revision: https://reviews.llvm.org/D147689
show more ...
|
#
83a635c0 |
| 12-Jan-2023 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add support for interface inheritance
This allows for interfaces to define a set of "base classes", which are interfaces whose methods/extra class decls/etc. should be inherited by the derive
[mlir] Add support for interface inheritance
This allows for interfaces to define a set of "base classes", which are interfaces whose methods/extra class decls/etc. should be inherited by the derived interface. This more easily enables combining interfaces and their dependencies, without lots of awkard casting. Additional implicit conversion operators also greatly simplify the conversion process.
One other aspect of this "inheritance" is that we also implicitly add the base interfaces to the attr/op/type. The user can still add them manually if desired, but this should help remove some of the boiler plate when an interface has dependencies.
See https://discourse.llvm.org/t/interface-inheritance-and-dependencies-interface-method-visibility-interface-composition
Differential Revision: https://reviews.llvm.org/D140198
show more ...
|
#
5cdc2bbc |
| 16-Dec-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Move SymbolOpInterfaces "classof" check to a proper "extraClassOf" interface field
SymbolOpInterface overrides the base classof to provide support for optionally implementing the interface. T
[mlir] Move SymbolOpInterfaces "classof" check to a proper "extraClassOf" interface field
SymbolOpInterface overrides the base classof to provide support for optionally implementing the interface. This is currently placed in the extraClassDeclarations, but that is kind of awkard given that it requires underlying knowledge of how the base classof is implemented. This commit adds a proper "extraClassOf" field to allow interfaces to implement this, which abstracts away the default classof logic.
Differential Revision: https://reviews.llvm.org/D140197
show more ...
|
#
3e731af9 |
| 15-Dec-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Limit Interface generation to the top-level input file
There are very few instances in which we use multiple files for interface definitions (none upstream), and this allows for including int
[mlir] Limit Interface generation to the top-level input file
There are very few instances in which we use multiple files for interface definitions (none upstream), and this allows for including interfaces that shouldn't be generated (for interface inheritance, dependencies, etc.)
Differential Revision: https://reviews.llvm.org/D140196
show more ...
|
#
794056e8 |
| 22-Dec-2022 |
Schuyler Eldridge <schuyler.eldridge@sifive.com> |
[mlir] Fix missing OpInterface docs newline
Fix incorrect markdown generated by mlir-tblgen for an InterfaceMethod that includes a body. Previously, this would cause the next method to show up on t
[mlir] Fix missing OpInterface docs newline
Fix incorrect markdown generated by mlir-tblgen for an InterfaceMethod that includes a body. Previously, this would cause the next method to show up on the same line and produce incorrect markdown. Newlines would only be added if the method did _not_ provide a body. E.g., previously this was generating markdown like:
some function comment#### `next method`
This change makes this generate as:
some function comment
#### `next method`
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D140590
show more ...
|
#
3cfe412e |
| 06-Dec-2022 |
Fangrui Song <i@maskray.me> |
[TableGen] llvm::Optional => std::optional
|
#
5e4eec98 |
| 21-Oct-2022 |
Alex Zinenko <zinenko@google.com> |
[mlir] ODS: emit interface model method at the end of the header
Previously, ODS interface generator was placing implementations of the interface's internal "Model" class template immediately after
[mlir] ODS: emit interface model method at the end of the header
Previously, ODS interface generator was placing implementations of the interface's internal "Model" class template immediately after the class definitions in the header. This doesn't allow this implementation, and consequently the interface itself, to return an instance of another interface if its class definition is emitted below. This creates undesired ordering effects and makes it impossible for two or more interfaces to return instances of each other. Change the interface generator to place the implementations of these methods after all interface classes.
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D136322
show more ...
|
#
2e2ad539 |
| 10-Aug-2022 |
Alex Zinenko <zinenko@google.com> |
[mlir] Generate C++ doc comments for interfaces
When emitting the declarations for interface methods defined in ODS, also emit their descriptions as C++ comments. This makes the documentation access
[mlir] Generate C++ doc comments for interfaces
When emitting the declarations for interface methods defined in ODS, also emit their descriptions as C++ comments. This makes the documentation accessible to C++ tooling such as IDEs that offers better usability than reading it form the .td or the website.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D130478
show more ...
|
#
9c8fe394 |
| 15-Jun-2022 |
Alex Zinenko <zinenko@google.com> |
[mlir] check interfaces are attached to the expected object
Add static assertions into the various `attachInterface` methods, which are used for adding external interface implementations to attribut
[mlir] check interfaces are attached to the expected object
Add static assertions into the various `attachInterface` methods, which are used for adding external interface implementations to attributes, operations and types, that ensure `ExternalModel` interface classes are instantiated for the same concrete operation for the concrete base (potentially self) attribute or type as they are attached to. `FallbackModel`s remain usable for generic interface models that should support more than one kind of entities.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D127850
show more ...
|
#
9445b396 |
| 25-Feb-2022 |
Chia-hung Duan <chiahungduan@google.com> |
[mlir] Support verification order (2/3)
This change gives explicit order of verifier execution and adds `hasRegionVerifier` and `verifyWithRegions` to increase the granularity of verifie
[mlir] Support verification order (2/3)
This change gives explicit order of verifier execution and adds `hasRegionVerifier` and `verifyWithRegions` to increase the granularity of verifier classification. The orders are as below,
1. InternalOpTrait will be verified first, they can be run independently. 2. `verifyInvariants` which is constructed by ODS, it verifies the type, attributes, .etc. 3. Other Traits/Interfaces that have marked their verifier as `verifyTrait` or `verifyWithRegions=0`. 4. Custom verifier which is defined in the op and has marked `hasVerifier=1`
If an operation has regions, then it may have the second phase,
5. Traits/Interfaces that have marked their verifier as `verifyRegionTrait` or `verifyWithRegions=1`. This implies the verifier needs to access the operations in its regions. 6. Custom verifier which is defined in the op and has marked `hasRegionVerifier=1`
Note that the second phase will be run after the operations in the region are verified. Based on the verification order, you will be able to avoid verifying duplicate things.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D116789
show more ...
|
#
78fdbdbf |
| 18-Jan-2022 |
Mehdi Amini <joker.eph@gmail.com> |
Use reference for large object passed by value at the moment in MLIR TableGen (NFC)
Also make the ODS Operator class have const iterator, and use const references for existing API taking Operator by
Use reference for large object passed by value at the moment in MLIR TableGen (NFC)
Also make the ODS Operator class have const iterator, and use const references for existing API taking Operator by reference.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D117516
show more ...
|
#
a60e83fe |
| 08-Jan-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][Interfaces] Add a extraSharedClassDeclaration field
This field allows for defining a code block that is placed in both the interface and trait declarations. This is very useful when defining
[mlir][Interfaces] Add a extraSharedClassDeclaration field
This field allows for defining a code block that is placed in both the interface and trait declarations. This is very useful when defining a set of utilities to expose on both the Interface class and the derived attribute/operation/type.
In non-static methods, `$_attr`/`$_op`/`$_type` (depending on the type of interface) may be used to refer to an instance of the IR entity. In the interface declaration, this is an instance of the interface class. In the trait declaration, this is an instance of the concrete entity class (e.g. `IntegerAttr`, `FuncOp`, etc.).
Differential Revision: https://reviews.llvm.org/D116961
show more ...
|
#
1fc096af |
| 02-Jan-2022 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for performance-unnecessary-value-param to MLIR (NFC)
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D116250
|
#
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 ...
|
#
49d840c3 |
| 22-Jul-2021 |
Marius Brehler <marius.brehler@iml.fraunhofer.de> |
[mlir] Improve description of interface options
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D106539
|