[mlir] Use value instead of getValue (NFC)

[mlir] Use has_value instead of hasValue (NFC)

[mlir] Update flipped accessors (NFC)

Follow up with memref flipped and flipping any intermediate changes
made.

Apply clang-tidy fixes for readability-simplify-boolean-expr in Shape.cpp (NFC)

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[mlir][shape] Switch types to ODS generated (NFC)

These were already pretty simple, so just switching to generated.

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

[mlir] Add shape.func

Add shape func op for use (primarily) in shape function_library op. Allows
setting default dialect for some simpler authoring. This is a minimal version
of the ops needed.

Dif

[mlir] Add shape.func

Add shape func op for use (primarily) in shape function_library op. Allows
setting default dialect for some simpler authoring. This is a minimal version
of the ops needed.

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

show more ...

[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace

FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.

Fixes https://github.com/llvm/llvm-project/issues/54446

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

show more ...

Apply clang-tidy fixes for readability-identifier-naming to MLIR (NFC)

[mlir] Region/BranchOpInterface: Allow implicit type conversions along control-flow edges

RegionBranchOpInterface and BranchOpInterface are allowed to make implicit type conversions along control-fl

[mlir] Region/BranchOpInterface: Allow implicit type conversions along control-flow edges

RegionBranchOpInterface and BranchOpInterface are allowed to make implicit type conversions along control-flow edges. In effect, this adds an interface method, `areTypesCompatible`, to both interfaces, which should return whether the types of corresponding successor operands and block arguments are compatible. Users of the interfaces, here on forth, must be aware that types may mismatch, although current users (in MLIR core), are not affected by this change. By default, type equality is used.

`async.execute` already has unequal types along control-flow edges (`!async.value<f32>` vs. `f32`), but it opted out of calling `RegionBranchOpInterface::verifyTypes` in its verifier. That method has now been removed and `RegionBranchOpInterface` will verify types along control edges by default in its verifier.

Reviewed By: rriddle

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

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

[Shape] Simplify getShapeVec a bit. NFCI.

Remove restriction on static dimensions in Shape method

mlir::shape::ToExtentTensorOp::areCastCompatible didn't allow the input
to have a static dimension, but that is allowed.

[mlir] Update uses of `parser`/`printer` ODS op field to `hasCustomAssemblyFormat`

The parser/printer fields are deprecated and in the process of being removed.

[mlir][NFC] Remove deprecated/old build/fold/parser utilities from OpDefinition

These have generally been replaced by better ODS functionality, and do not
need to be explicitly provided anymore.

Di

[mlir][NFC] Remove deprecated/old build/fold/parser utilities from OpDefinition

These have generally been replaced by better ODS functionality, and do not
need to be explicitly provided anymore.

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

show more ...

[mlir] Add canonicalizer to remove redundant shape.cstr_broadcastable ops

Depends On D119025

Reviewed By: frgossen

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

[mlir] Add canonicalizer to merge shape.assuming_all ops

Depends On D119021

Reviewed By: frgossen

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

[mlir] Use SetVector to deduplicate shape ops operands

Do not use quadratic complexity algorithm to find unique operands

Reviewed By: jpienaar

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

[mlir] Use SetVector to deduplicate shape ops operands

Do not use quadratic complexity algorithm to find unique operands

Reviewed By: jpienaar

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

show more ...

[mlir][NFC] Update remaining dialect operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update remaining dialect operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

show more ...

[mlir] Remove a bunch of unnecessary dialect dependencies

A lot of dialects have dependencies that are unnecessary, either because of copy/paste
of files when creating things or some other means. Th

[mlir] Remove a bunch of unnecessary dialect dependencies

A lot of dialects have dependencies that are unnecessary, either because of copy/paste
of files when creating things or some other means. This commit cleans up a bunch of
the simple ones:

* Copy/Paste or missed during refactoring
Most of the dependencies cleaned up here look like copy/paste errors when creating
new dialects/transformations, or because the dependency wasn't removed during a
refactoring (e.g. when splitting the standard dialect).

* Unnecessary hard coding of constant operations in matchers
There are a few instances where a dialect had a dependency because it
was hardcoding checks for constant operations instead of using the better m_Constant
approach.

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

show more ...

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against th

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.

Fixes #53279

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

show more ...

[mlir] Drop the leading space when printing regions

The leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leadin

[mlir] Drop the leading space when printing regions

The leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leading space can lead to undesirable assembly formats:

```
attr-dict-with-keyword $region
```

Prints as:

```
// Two spaces between `}` and `{`
attributes {foo} { ... }
```

Moreover, the leading space results in the odd generic op format:

```
"test.op"() ( {...}) : () -> ()
```

Reviewed By: rriddle, mehdi_amini

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

show more ...