delta/llvm.git/mlir/include, branch EmptyLineAfterFunctionDefinition

[mlir][linalg][bufferize][NFC] Decouple ComprehensiveBufferize from tensor dialect

2021-11-18T07:11:24+00:00

Add a new BufferizableOpInterface method `isNotConflicting` that can be used to implement custom analysis rules.

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

[mlir] Convert NamedAttribute to be a class

2021-11-18T05:39:29+00:00

NamedAttribute is currently represented as an std::pair, but this
creates an extremely clunky .first/.second API. This commit
converts it to a class, with better accessors (getName/getValue)
and also opens the door for more convenient API in the future.

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

[mlir] Refactor AbstractOperation and OperationName

2021-11-17T22:29:57+00:00

The current implementation is quite clunky; OperationName stores either an Identifier
or an AbstractOperation that corresponds to an operation. This has several problems:

* OperationNames created before and after an operation are registered are different
* Accessing the identifier name/dialect/etc. from an OperationName are overly branchy
  - they need to dyn_cast a PointerUnion to check the state

This commit refactors this such that we create a single information struct for every
operation name, even operations that aren't registered yet. When an OperationName is
created for an unregistered operation, we only populate the name field. When the
operation is registered, we populate the remaining fields. With this we now have two
new classes: OperationName and RegisteredOperationName. These both point to the
same underlying operation information struct, but only RegisteredOperationName can
assume that the operation is actually registered. This leads to a much cleaner API, and
we can also move some AbstractOperation functionality directly to OperationName.

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

[mlir][Vector] First step for 0D vector type

2021-11-17T14:58:24+00:00

There seems to be a consensus that we should allow 0D vectors:
https://llvm.discourse.group/t/should-we-have-0-d-vectors/3097

This commit is only the first step: it changes the verifier and the parser to
allow vectors like `vector` (but does not allow explicit 0 dimensions,
i.e., `vector<0xf32>` is not allowed).

Reviewed By: nicolasvasilache

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

[mlir] Fix formatting in Ops.td files (NFC)

2021-11-17T00:59:42+00:00

MemRefOps.td has some inconsistencies in its formatting of argument
lists.

[mlir][lsp] Use ResultGroupDefinition struct

2021-11-17T00:40:57+00:00

This struct was added and was intended to be used, but it was missed in the original patch.

Reviewed By: rriddle

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

[mlir] Fix clang5 build after D113641

2021-11-16T19:49:17+00:00

[llvm] Add a SFINAE template parameter to DenseMapInfo

2021-11-16T18:54:14+00:00

This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.

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

[mlir][NFC] Replace references to Identifier with StringAttr

2021-11-16T17:36:26+00:00

This is part of the replacement of Identifier with StringAttr.

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

[MLIR][LLVM] Permit integer types in switch other than i32

2021-11-16T17:00:37+00:00

LLVM switchop currently only permits i32. Both LLVM IR and MLIR Standard switch permit other integer types leading to an illegal state when lowering an i8 switch from MLIR standard

Reviewed By: mehdi_amini

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