History log of /llvm-project/mlir/tools/mlir-tblgen/OpInterfacesGen.cpp (Results 1 – 25 of 54)
Revision Date Author Comments
# 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


123