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

[mlir:ODS] Support using attributes in AllTypesMatch to automatically add InferTypeOpInterface

This allows for using attribute types in result type inference for use with
InferTypeOpInterface. This

[mlir:ODS] Support using attributes in AllTypesMatch to automatically add InferTypeOpInterface

This allows for using attribute types in result type inference for use with
InferTypeOpInterface. This was a TODO before, but it isn't much
additional work to properly support this. After this commit,
arith::ConstantOp can now have its InferTypeOpInterface implementation automatically
generated.

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

show more ...

[mlir][ODS] Infer return types if the operands are variadic but the results are not

Clean up code that worked around this limitation.

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

[mlir][ods] Allow type attribute/operand for 0 result ops prefixed

Without results, there is no getType injected and so generating one in prefixed form doesn't result in any failures during C++ comp

[mlir][ods] Allow type attribute/operand for 0 result ops prefixed

Without results, there is no getType injected and so generating one in prefixed form doesn't result in any failures during C++ compilation.

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

show more ...

[mlir] Support verification order (1/3)

This CL supports adding dependency between traits verifiers and the
dependency will be checked statically.

Reviewed By: jpienaar

Differential Revision: http

[mlir] Support verification order (1/3)

This CL supports adding dependency between traits verifiers and the
dependency will be checked statically.

Reviewed By: jpienaar

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

show more ...

Remove OpTrait, AttrTrait and TypeTrait

- Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait`
- Rename `OpTraitList` to `TraitList` and use it in a few places

The bulk of

Remove OpTrait, AttrTrait and TypeTrait

- Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait`
- Rename `OpTraitList` to `TraitList` and use it in a few places

The bulk of this change is a mechanical s/OpTrait/Trait/ throughout the codebase.

Reviewed By: rriddle, jpienaar, herhut

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

show more ...

[mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.h

These are used pervasively during parsing.

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

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

[mlir][ods] ODS ops get an `extraClassDefinition`

Extra definitions are placed in the generated source file for each op class. The substitution `$cppClass` is replaced by the op's C++ class name.

T

[mlir][ods] ODS ops get an `extraClassDefinition`

Extra definitions are placed in the generated source file for each op class. The substitution `$cppClass` is replaced by the op's C++ class name.

This is useful when declaring but not defining methods in TableGen base classes:

```
class BaseOp<string mnemonic>
: Op<MyDialect, mnemonic, [DeclareOpInterfaceMethods<SomeInterface>] {
let extraClassDeclaration = [{
// ZOp is declared at at the bottom of the file and is incomplete here
ZOp getParent();
}];
let extraClassDefinition = [{
int $cppClass::someInterfaceMethod() {
return someUtilityFunction(*this);
}
ZOp $cppClass::getParent() {
return dyn_cast<ZOp>(this->getParentOp());
}
}];
}
```

Certain things may prevent defining these functions inline, in the declaration. In this example, `ZOp` in the same dialect is incomplete at the function declaration because ops classes are declared in alphabetical order. Alternatively, functions may be too big to be desired as inlined, or they may require dependencies that create cyclic includes, or they may be calling a templated utility function that one may not want to expose in a header. If the functions are not inlined, then inheriting from the base class N times means that each function will need to be defined N times. With `extraClassDefinitions`, they only need to be defined once.

Reviewed By: rriddle

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

show more ...

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

[mlir] Fix missing prefix for region accessor on OpAdaptor

Also flip op-decl-and-defs test to _Prefixed to test more.

[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.

Following
https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis

[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.

Following
https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476,
this follows flipping these dialects to _Both prefixed form. This
changes the accessors to have a prefix. This was possibly mostly without
breaking breaking changes if the existing convenience methods were used.

(https://github.com/jpienaar/llvm-project/blob/main/clang-tools-extra/clang-tidy/misc/AddGetterCheck.cpp
was used to migrate the callers post flipping, using the output from
Operator.cpp)

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

show more ...

[mlir] Expand prefixing to OpFormatGen

Follow up to also use the prefixed emitters in OpFormatGen (moved
getGetterName(s) and getSetterName(s) to Operator as that is most
convenient usage wise even

[mlir] Expand prefixing to OpFormatGen

Follow up to also use the prefixed emitters in OpFormatGen (moved
getGetterName(s) and getSetterName(s) to Operator as that is most
convenient usage wise even though it just depends on Dialect). Prefix
accessors in Test dialect and follow up on missed changes in
OpDefinitionsGen.

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

show more ...

Add sanity check in MLIR ODS to catch case where an arguments/results/regions/successors names overlap

This is making a tablegen crash with a more friendly error.

Differential Revision: https://rev

Add sanity check in MLIR ODS to catch case where an arguments/results/regions/successors names overlap

This is making a tablegen crash with a more friendly error.

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

show more ...

[mlir] Add support for VariadicOfVariadic operands

This revision adds native ODS support for VariadicOfVariadic operand
groups. An example of this is the SwitchOp, which has a variadic number
of nes

[mlir] Add support for VariadicOfVariadic operands

This revision adds native ODS support for VariadicOfVariadic operand
groups. An example of this is the SwitchOp, which has a variadic number
of nested operand ranges for each of the case statements, where the
number of case statements is variadic. Builtin ODS support allows for
generating proper accessors for the nested operand ranges, builder
support, and declarative format support. VariadicOfVariadic operands
are supported by providing a segment attribute to use to store the
operand groups, mapping similarly to the AttrSizedOperand trait
(but with a user defined attribute name).

`build` methods for VariadicOfVariadic operand expect inputs of the
form `ArrayRef<ValueRange>`. Accessors for the variadic ranges
return a new `OperandRangeRange` type, which represents a
contiguous range of `OperandRange`. In the declarative assembly
format, VariadicOfVariadic operands and types are by default
formatted as a comma delimited list of value lists:
`(<value>, <value>), (), (<value>)`.

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

show more ...

[mlir][ods] Add nested OpTrait

Allows for grouping OpTraits with list of OpTrait to make it easier to group OpTraits together without needing to use list concats (e.g., enable using `[Traits, ..., U

[mlir][ods] Add nested OpTrait

Allows for grouping OpTraits with list of OpTrait to make it easier to group OpTraits together without needing to use list concats (e.g., enable using `[Traits, ..., UsefulGroupOfTraits, Others, ...]` instead of `[Traits, ...] # UsefulGroupOfTraits # [Others, ...]`). Flatten in construction of Operation. This recurses here as the expectation is that these aren't expected to be deeply nested (most likely only 1 level of nesting).

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

show more ...

[mlir][ODS]: Add per-op cppNamespace.

This is useful for dialects that have logical subparts.

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

[mlir] Add support for adding attribute+type traits/interfaces to tablegen defs

This matches the current support provided to operations, and allows attaching traits, interfaces, and using the Declar

[mlir] Add support for adding attribute+type traits/interfaces to tablegen defs

This matches the current support provided to operations, and allows attaching traits, interfaces, and using the DeclareInterfaceMethods utility. This was missed when attribute/type generation was first added.

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

show more ...

[mlir][ODS] Add a C++ abstraction for OpBuilders

This removes the need for OpDefinitionsGen to use raw tablegen API, and will also
simplify adding builders to TypeDefs as well.

Differential Revisio

[mlir][ODS] Add a C++ abstraction for OpBuilders

This removes the need for OpDefinitionsGen to use raw tablegen API, and will also
simplify adding builders to TypeDefs as well.

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

show more ...

[TableGen] Eliminate the 'code' type

Update the documentation.

Rework various backends that relied on the code type.

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

[mlir] Add basic support for attributes in ODS-generated Python bindings

In ODS, attributes of an operation can be provided as a part of the "arguments"
field, together with operands. Such attribute

[mlir] Add basic support for attributes in ODS-generated Python bindings

In ODS, attributes of an operation can be provided as a part of the "arguments"
field, together with operands. Such attributes are accepted by the op builder
and have accessors generated.

Implement similar functionality for ODS-generated op-specific Python bindings:
the `__init__` method now accepts arguments together with operands, in the same
order as in the ODS `arguments` field; the instance properties are introduced
to OpView classes to access the attributes.

This initial implementation accepts and returns instances of the corresponding
attribute class, and not the underlying values since the mapping scheme of the
value types between C++, C and Python is not yet clear. Default-valued
attributes are not supported as that would require Python to be able to parse
C++ literals.

Since attributes in ODS are tightely related to the actual C++ type system,
provide a separate Tablegen file with the mapping between ODS storage type for
attributes (typically, the underlying C++ attribute class), and the
corresponding class name. So far, this might look unnecessary since all names
match exactly, but this is not necessarily the cases for non-standard,
out-of-tree attributes, which may also be placed in non-default namespaces or
Python modules. This also allows out-of-tree users to generate Python bindings
without having to modify the bindings generator itself. Storage type was
preferred over the Tablegen "def" of the attribute class because ODS
essentially encodes attribute _constraints_ rather than classes, e.g. there may
be many Tablegen "def"s in the ODS that correspond to the same attribute type
with additional constraints

The presence of the explicit mapping requires the change in the .td file
structure: instead of just calling the bindings generator directly on the main
ODS file of the dialect, it becomes necessary to create a new file that
includes the main ODS file of the dialect and provides the mapping for
attribute types. Arguably, this approach offers better separability of the
Python bindings in the build system as the main dialect no longer needs to know
that it is being processed by the bindings generator.

Reviewed By: stellaraccident

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

show more ...

Common code preparation for tblgen-types patch

Cleanup and add methods which https://reviews.llvm.org/D86904 requires. Breaking up to lower review load.

Reviewed By: mehdi_amini

Differential Revis

Common code preparation for tblgen-types patch

Cleanup and add methods which https://reviews.llvm.org/D86904 requires. Breaking up to lower review load.

Reviewed By: mehdi_amini

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

show more ...

Make namespace handling uniform across dialect backends.

Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. Th

Make namespace handling uniform across dialect backends.

Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. This also means that
cppNamespaces should be fully qualified, and there's no implicit "::mlir::"
prepended to them anymore.

Reviewed By: mehdi_amini

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

show more ...

[MLIR][NFC] Remove tblgen:: prefix in TableGen/*.cpp files

- Add "using namespace mlir::tblgen" in several of the TableGen/*.cpp files and
eliminate the tblgen::prefix to reduce code clutter.

Dif

[MLIR][NFC] Remove tblgen:: prefix in TableGen/*.cpp files

- 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

show more ...