[MLIR][TableGen] Use arg index in InferredResultType constructor. (#122717)

Trying to constrain two results to be of the same type using
`AllTypesMatch` would cause `mlir-tablgen` to crash on this

[MLIR][TableGen] Use arg index in InferredResultType constructor. (#122717)

Trying to constrain two results to be of the same type using
`AllTypesMatch` would cause `mlir-tablgen` to crash on this
assertion[1].

Example:

```tblgen
def OpL5 : NS_Op<"op_with_same_but_unconstraint_results",
[AllTypesMatch<["result_a", "result_b"]>]> {
let results = (outs AnyType:$result_a, AnyType:$result_b);
}
```

This is because there was a small bug when constructing the `inferences`
graph from these constraints: The sources should be specified by the
combined arg/result index (in other words, with results negative) not
with the result index.


[1]
https://github.com/llvm/llvm-project/blob/99612a3a18e0c40aac9c52b68e67b106f97ed4fa/mlir/lib/TableGen/Operator.cpp#L526

show more ...

[TableGen] Migrate away from PointerUnion::{is,get} (NFC) (#122569)

Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:

// FIXME: Replace the uses of is(), get() and

[TableGen] Migrate away from PointerUnion::{is,get} (NFC) (#122569)

Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:

// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>

show more ...

[NFC][MLIR][TableGen] Eliminate `llvm::` for commonly used types (#112456)

Eliminate `llvm::` namespace qualifier for commonly used types in MLIR
TableGen backends to reduce code clutter.

[MLIR][TableGen] Use const pointers for various `Init` objects (#112562)

This reverts commit 0eed3055511381436ee69d1caf64a4af47f8d65c and applies
additional fixes in `verifyArgument` in OmpOpGen.cp

[MLIR][TableGen] Use const pointers for various `Init` objects (#112562)

This reverts commit 0eed3055511381436ee69d1caf64a4af47f8d65c and applies
additional fixes in `verifyArgument` in OmpOpGen.cpp for gcc-7 bot
failures

show more ...

Revert "[MLIR][TableGen] Use const pointers for various `Init` objects" (#112506)

Reverts llvm/llvm-project#112316

Bots are failing.

[MLIR][TableGen] Use const pointers for various `Init` objects (#112316)

Use const pointers for various `Init` objects. This is a part of effort
to have better const correctness in TableGen backend

[MLIR][TableGen] Use const pointers for various `Init` objects (#112316)

Use const pointers for various `Init` objects. 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

show more ...

[TableGen] Change `DefInit::Def` to a const Record pointer (#110747)

This change undoes a const_cast<> introduced in an earlier change to
help transition to const pointers. It is a part of effort t

[TableGen] Change `DefInit::Def` to a const Record pointer (#110747)

This change undoes a const_cast<> introduced in an earlier change to
help transition to const pointers. It 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

show more ...

[mlir] [tablegen] Make `hasSummary` and `hasDescription` useful (#105531)

The `hasSummary` and `hasDescription` functions are currently useless as
they check if the corresponding `summary` and `des

[mlir] [tablegen] Make `hasSummary` and `hasDescription` useful (#105531)

The `hasSummary` and `hasDescription` functions are currently useless as
they check if the corresponding `summary` and `description` are present.
However, these values are set to a default value of `""`, and so these
functions always return true.

This PR changes these functions to check if the summary and description
are just whitespace, which is presumably closer to their original
intent.

@math-fehr
@zero9178

show more ...

Add support for versioning properties in MLIR bytecode

[mlir] Add support for custom readProperties/writeProperties methods.

Currently, operations that opt-in to adopt properties will see auto-gene

Add support for versioning properties in MLIR bytecode

[mlir] Add support for custom readProperties/writeProperties methods.

Currently, operations that opt-in to adopt properties will see auto-generated readProperties/writeProperties methods to emit and parse bytecode. If a dialects opts in to use `usePropertiesForAttributes`, those definitions will be generated for the current definition of the op without the possibility to handle attribute versioning.

The patch adds the capability for an operation to define its own read/write methods for the encoding of properties so that versioned operations can handle upgrading properties encodings.

In addition to this, the patch adds an example showing versioning on NamedProperties through the dialect version API exposed by the reader.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D155340

show more ...

[mlir] Move casting calls from methods to function calls

The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionali

[mlir] Move casting calls from methods to function calls

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.

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 patch updates all remaining uses of the deprecated functionality in
mlir/. This was done with clang-tidy as described below and further
modifications to GPUBase.td and OpenMPOpsInterfaces.td.

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:
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.

```
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
```

Differential Revision: https://reviews.llvm.org/D151542

show more ...

Introduce MLIR Op Properties

This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to

Introduce MLIR Op Properties

This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:

struct TestProperties {
int a = -1;
float b = -1.;
std::vector<int64_t> array = {-33};
};

More complex scheme (including reference-counting) are also possible.

The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:

- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object

Optional the parsing and printing can also be customized with 2 extra
functions.

A new options is introduced to ODS to allow dialects to specify:

let usePropertiesForAttributes = 1;

When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.

Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.

Recommit d572cd1b067f after fixing python bindings build.

Differential Revision: https://reviews.llvm.org/D141742

show more ...

Revert "Introduce MLIR Op Properties"

This reverts commit d572cd1b067f1177a981a4711bf2e501eaa8117b.

Some bots are broken and investigation is needed before relanding.

Introduce MLIR Op Properties

This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to

Introduce MLIR Op Properties

This new features enabled to dedicate custom storage inline within operations.
This storage can be used as an alternative to attributes to store data that is
specific to an operation. Attribute can also be stored inside the properties
storage if desired, but any kind of data can be present as well. This offers
a way to store and mutate data without uniquing in the Context like Attribute.
See the OpPropertiesTest.cpp for an example where a struct with a
std::vector<> is attached to an operation and mutated in-place:

struct TestProperties {
int a = -1;
float b = -1.;
std::vector<int64_t> array = {-33};
};

More complex scheme (including reference-counting) are also possible.

The only constraint to enable storing a C++ object as "properties" on an
operation is to implement three functions:

- convert from the candidate object to an Attribute
- convert from the Attribute to the candidate object
- hash the object

Optional the parsing and printing can also be customized with 2 extra
functions.

A new options is introduced to ODS to allow dialects to specify:

let usePropertiesForAttributes = 1;

When set to true, the inherent attributes for all the ops in this dialect
will be using properties instead of being stored alongside discardable
attributes.
The TestDialect showcases this feature.

Another change is that we introduce new APIs on the Operation class
to access separately the inherent attributes from the discardable ones.
We envision deprecating and removing the `getAttr()`, `getAttrsDictionary()`,
and other similar method which don't make the distinction explicit, leading
to an entirely separate namespace for discardable attributes.

Differential Revision: https://reviews.llvm.org/D141742

show more ...

[ADT][mlir][NFCI] Do not use non-const lvalue-refs with enumerate

Replace references to enumerate results with either result_pairs
(reference wrapper type) or structured bindings. I did not use
stru

[ADT][mlir][NFCI] Do not use non-const lvalue-refs with enumerate

Replace references to enumerate results with either result_pairs
(reference wrapper type) or structured bindings. I did not use
structured bindings everywhere as it wasn't clear to me it would
improve readability.

This is in preparation to the switch to zip semantics which won't
support non-const lvalue reference to elements:
https://reviews.llvm.org/D144503.

I chose to use values instead of const lvalue-refs because MLIR is
biased towards avoiding `const` local variables. This won't degrade
performance because currently `result_pair` is cheap to copy (size_t
+ iterator), and in the future, the enumerator iterator dereference
will return temporaries anyway.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D146006

show more ...

[mlir] Use Use *{Set,Map}::contains (NFC)

[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 ...

[mlir][tblgen] Fix undefined behaviour found by MSVC debug iterators

Incrementing past the end iterator of any container in C++ is immediate undefined behaviour.
This is guaranteed to occur in the l

[mlir][tblgen] Fix undefined behaviour found by MSVC debug iterators

Incrementing past the end iterator of any container in C++ is immediate undefined behaviour.
This is guaranteed to occur in the loop condition due to the expression cur = earlyIncIt++, which when earlyIncIt is the end iterator (aka we just did the last iteration of the loop), will do an increment on the end iterator.

To fix this, the patch refactors the loop to a more conventional loop using iterators, with the only difference being that the increment happens through the erase operation, which conveniently returns an iterator to the element after the erased element. Thanks to that guarantee there is also no need to use std::list over std::vector.
I also opted to reduce the inner loop find_if, because I felt splitting the "search" and the effects of if it was successful made the code (subjectively) nicer, and also avoided having to add an extra "bool erased" to the outer loop body.

Differential Revision: https://reviews.llvm.org/D141758

show more ...

[mlir][ods] Generate inferReturnTypes for ops with TypesMatchWith

Ops that use TypesMatchWith to constrain result types for verification
and to infer result types during parser generation should als

[mlir][ods] Generate inferReturnTypes for ops with TypesMatchWith

Ops that use TypesMatchWith to constrain result types for verification
and to infer result types during parser generation should also be able
to have the `inferReturnTypes` method auto generated. This patch
upgrades the logic for generating `inferReturnTypes` to handle the
TypesMatchWith trait by building a type inference graph where each edge
corresponds to "type of A can be inferred from type of B", supporting
transformers other than `"$_self"`.

Reviewed By: lattner, rriddle

Differential Revision: https://reviews.llvm.org/D141231

show more ...

[mlir] Add a new fold API using Generic Adaptors

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch imple

[mlir] Add a new fold API using Generic Adaptors

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the required foldHook changes and the TableGen machinery for generating `fold` method signatures using `FoldAdaptor` for ops, based on the value of `useFoldAPI` of the dialect. It may be one of 2 values, with convenient named constants to create a quasi enum. The new `fold` method will then be generated if `kEmitFoldAdaptorFolder` is used.

Since the new `FoldAdaptor` approach is strictly better than the old signature, part of this patch updates the documentation and all example to encourage use of the new `fold` signature.
Included are also tests exercising the new API, ensuring proper construction of the `FoldAdaptor` and proper generation by TableGen.

Differential Revision: https://reviews.llvm.org/D140886

show more ...

[mlir][tblgen] Generate generic adaptors for Ops

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch imple

[mlir][tblgen] Generate generic adaptors for Ops

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the generation of generic adaptors through TableGen. These are essentially a generalization of Adaptors, as implemented previously, but instead of indexing into a `mlir::ValueRange`, they may index into any container, regardless of the element type. This allows the use of the convenient getter methods of Adaptors to be reused on ranges that are the result of some kind of mapping functions of an ops operands.
In the case of the fold API in the RFC, this would be `ArrayRef<Attribute>`, which is a mapping of the operands to their possibly-constant values.

Implementation wise, some special care was taken to not cause a compile time regression, nor to break any kind of source compatibility.
For that purpose, the current adaptor class was split into three:
* A generic adaptor base class, within the detail namespace as it is an implementation detail, which implements all APIs independent of the range type used for the operands. This is all the attribute and region related code. Since it is not templated, its implementation does not have to be inline and can be put into the cpp source file
* The actual generic adaptor, which has a template parameter for the range that should be indexed into for retrieving operands. It implements all the getters for operands, as they are dependent on the range type. It publicly inherits from the generic adaptor base class
* A class named as adaptors have been named so far, inheriting from the generic adaptor class with `mlir::ValueRange` as range to index into. It implements the rest of the API, specific to `mlir::ValueRange` adaptors, which have previously been part of the adaptor. This boils down to a constructor from the Op type as well as the verify function.

The last class having the exact same API surface and name as Adaptors did previously leads to full source compatibility.

Differential Revision: https://reviews.llvm.org/D140660

show more ...

[mlir][ods] Generate remover methods with camelcase

The remove*Attr methods were not being generated with the correct
camelcase method.

Depends on D139470

Reviewed By: rriddle

Differential Revisi

[mlir][ods] Generate remover methods with camelcase

The remove*Attr methods were not being generated with the correct
camelcase method.

Depends on D139470

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D139471

show more ...

[mlir] Remove support for non-prefixed accessors

This finishes off a year long pursuit to LLVMify the generated
operation accessors, prefixing them with get/set. Support for
any other accessor namin

[mlir] Remove support for non-prefixed accessors

This finishes off a year long pursuit to LLVMify the generated
operation accessors, prefixing them with get/set. Support for
any other accessor naming is fully removed after this commit.

https://discourse.llvm.org/t/psa-raw-accessors-are-being-removed/65629

Differential Revision: https://reviews.llvm.org/D136727

show more ...

[mlir] Flip default value of emitAccessorPrefix to kEmitAccessorPrefix_Prefixed

Most dialects have already flipped to prefixed, and the intention to switch
has been telegraphed for a while.

Differe

[mlir] Flip default value of emitAccessorPrefix to kEmitAccessorPrefix_Prefixed

Most dialects have already flipped to prefixed, and the intention to switch
has been telegraphed for a while.

Differential Revision: https://reviews.llvm.org/D133179

show more ...

[mlir] Don't use Optional::hasValue (NFC)

[mlir] Attach InferTypeOpInterface on SameOperandsAndResultType operations when possible

This allows for inferring the result types of operations in certain situations by using the type of
an operan

[mlir] Attach InferTypeOpInterface on SameOperandsAndResultType operations when possible

This allows for inferring the result types of operations in certain situations by using the type of
an operand. This commit allowed for automatically supporting type inference for many more
operations with no additional effort, e.g. nearly all Arithmetic operations now support
result type inferrence with no additional changes.

Differential Revision: https://reviews.llvm.org/D124581

show more ...