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

[mlir] Refactor how additional verification is specified in ODS

Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite

[mlir] Refactor how additional verification is specified in ODS

Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite problematic for various reasons, e.g.
it requires defining C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to a static function `static LogicalResult verify(SomeOp op)`.
This commit adds support for a `hasVerifier` bit field that specifies if an additional verifier
is needed, and when set to `1` declares a `LogicalResult verify()` method for operations to
override. For migration purposes, the existing behavior is untouched. Upstream usages will
be replaced in a followup to keep this patch focused on the hasVerifier implementation.

One main user facing change is that what was one `MyOp::verify` is now `MyOp::verifyInvariants`.
This better matches the name this method is called everywhere else, and also frees up `verify` for
the user defined additional verification. The `verify` function when generated now (for additional
verification) is private to the operation class, which should also help avoid accidental usages after
this switch.

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

show more ...

[mlir][spirv] Fix nested control flow serialization

If we have a `spv.mlir.selection` op nested in a `spv.mlir.loop`
op, when serializing the loop's block, we might need to jump
from the selection o

[mlir][spirv] Fix nested control flow serialization

If we have a `spv.mlir.selection` op nested in a `spv.mlir.loop`
op, when serializing the loop's block, we might need to jump
from the selection op's merge block, which might be different
than the immediate MLIR IR predecessor block. But we still need
to get the block argument from the MLIR IR predecessor block.

Also, if the `spv.mlir.selection` is in the `spv.mlir.loop`'s
header block, we need to make sure `OpLoopMerge` is emitted
in the current block before start processing the nested selection
op. Otherwise we'll see the LoopMerge in the wrong SPIR-V
basic block.

Reviewed By: Hardcode84

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

show more ...

[mlir][spirv] Propagate LogicalResult in (de)serialization

`(void)` was added when LogicalResult was marked as non
discard. This commit cleans them up to properly propagate
failures.

Reviewed By: s

[mlir][spirv] Propagate LogicalResult in (de)serialization

`(void)` was added when LogicalResult was marked as non
discard. This commit cleans them up to properly propagate
failures.

Reviewed By: scotttodd

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

show more ...

[mlir][spirv] Avoid duplicated Block decoration during serialization

It's legal per the Vulkan / SPIR-V spec; still it's better to avoid
such duplication to have cleaner blob and reduce the binary s

[mlir][spirv] Avoid duplicated Block decoration during serialization

It's legal per the Vulkan / SPIR-V spec; still it's better to avoid
such duplication to have cleaner blob and reduce the binary size.

Reviewed By: scotttodd

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

show more ...

[mlir][spirv] Add serialization control to emit symbol name

In SPIR-V, symbol names are encoded as `OpName` instructions.
They are not semantic impacting and can be omitted, which can
reduce the bin

[mlir][spirv] Add serialization control to emit symbol name

In SPIR-V, symbol names are encoded as `OpName` instructions.
They are not semantic impacting and can be omitted, which can
reduce the binary size.

Reviewed By: scotttodd

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

show more ...

[mlir] Convert NamedAttribute to be a class

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

[mlir] Convert NamedAttribute to be a class

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

show more ...

[mlir] Refactor ElementsAttr's value access API

There are several aspects of the API that either aren't easy to use, or are
deceptively easy to do the wrong thing. The main change of this commit
is

[mlir] Refactor ElementsAttr's value access API

There are several aspects of the API that either aren't easy to use, or are
deceptively easy to do the wrong thing. The main change of this commit
is to remove all of the `getValue<T>`/`getFlatValue<T>` from ElementsAttr
and instead provide operator[] methods on the ranges returned by
`getValues<T>`. This provides a much more convenient API for the value
ranges. It also removes the easy-to-be-inefficient nature of
getValue/getFlatValue, which under the hood would construct a new range for
the type `T`. Constructing a range is not necessarily cheap in all cases, and
could lead to very poor performance if used within a loop; i.e. if you were to
naively write something like:

```
DenseElementsAttr attr = ...;
for (int i = 0; i < size; ++i) {
// We are internally rebuilding the APFloat value range on each iteration!!
APFloat it = attr.getFlatValue<APFloat>(i);
}
```

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

show more ...

[mlir][SPIRVToLLVM] Propagate location attribute from spv.GlobalVariable to llvm.mlir.global

This patch is mainly to propogate location attribute from spv.GlobalVariable to llvm.mlir.global.

It als

[mlir][SPIRVToLLVM] Propagate location attribute from spv.GlobalVariable to llvm.mlir.global

This patch is mainly to propogate location attribute from spv.GlobalVariable to llvm.mlir.global.

It also contains three small changes.

1. Remove the restriction on UniformConstant In SPIRVToLLVM.cpp;
2. Remove the errorCheck on relaxedPrecision when deserializering SPIR-V in Deserializer.cpp
3. In SPIRVOps.cpp, let ConstantOp take signedInteger too.

Co-authered: Alan Liu <[email protected]> and Xinyi Liu <[email protected]>

Reviewed by:antiagainst

Differential revision: https://reviews.llvm.org/D110207

show more ...

[mlir][spirv] Add support for i8 serialization

Reviewed By: hanchung

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

[mlir][spirv] Use SingleBlock + NoTerminator for spv.module

This allows us to remove the `spv.mlir.endmodule` op and
all the code associated with it.

Along the way, tightened the APIs for `spv.modu

[mlir][spirv] Use SingleBlock + NoTerminator for spv.module

This allows us to remove the `spv.mlir.endmodule` op and
all the code associated with it.

Along the way, tightened the APIs for `spv.module` a bit
by removing some aliases. Now we use `getRegion` to get
the only region, and `getBody` to get the region's only
block.

Reviewed By: mravishankar, hanchung

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

show more ...

[MLIR][SPIRV] Properly (de-)serialize BranchConditionalOp.

Implements proper (de-)serialization logic for BranchConditionalOp when
such ops have true/false target operands.

Reviewed By: antiagainst

[MLIR][SPIRV] Properly (de-)serialize BranchConditionalOp.

Implements proper (de-)serialization logic for BranchConditionalOp when
such ops have true/false target operands.

Reviewed By: antiagainst

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

show more ...

[mlir][NFC] Add a using directive for llvm::SetVector

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

[mlir][IR][NFC] Define the Location classes in ODS instead of C++

This also removes the need for LocationDetail.h.

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

[MLIR][SPIRV] Rename `spv.selection` to `spv.mlir.selection`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere. For ops t

[MLIR][SPIRV] Rename `spv.selection` to `spv.mlir.selection`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere. For ops that
don't have a SPIR-V spec counterpart, we use spv.mlir.snake_case.

Reviewed By: antiagainst

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

show more ...

[MLIR][SPIRV] Rename `spv.loop` to `spv.mlir.loop`.

To unify the naming scheme across all ops in the SPIR-V dialect,
we are moving from spv.camelCase to spv.CamelCase everywhere.

Reviewed By: antia

[MLIR][SPIRV] Rename `spv.loop` to `spv.mlir.loop`.

To unify the naming scheme across all ops in the SPIR-V dialect,
we are moving from spv.camelCase to spv.CamelCase everywhere.

Reviewed By: antiagainst

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

show more ...

[mlir][spirv] Add support for sampled image type

co-authored-by: Alan Liu <[email protected]>

Reviewed By: antiagainst

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

[MLIR][SPIRV] NFC: Split serialization code among multiple files.

Following up on https://reviews.llvm.org/D94360, this patch splits the
serialization code into multiple source files to provide a be

[MLIR][SPIRV] NFC: Split serialization code among multiple files.

Following up on https://reviews.llvm.org/D94360, this patch splits the
serialization code into multiple source files to provide a better
structure and allow parallel compilation.

Reviewed By: antiagainst

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

show more ...