8 Commits

Author SHA1 Message Date
River Riddle
4a3460a791 [mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"
This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes it
clear what the intent is (i.e. to represent the type of the function).

Differential Revision: https://reviews.llvm.org/D121762
2022-03-16 17:07:04 -07:00
Lei Zhang
5e55a20119 [mlir][spirv] Serialize selection with separate header block
The previous "optimization" that tries to reuse existing block for
selection header block can be problematic for deserialization
because it effectively pulls in previous ops in the selection op's
enclosing block into the selection op's header. When deserializing,
those ops will be placed in the selection op's region. If any of
the previous ops has usage after the section op, it will break. That
is, the following IR cannot round trip:

```mlir
^bb:
  %def = ...
  spv.mlir.selection { ... }
  %use = spv.SomeOp %def
```

This commit removes the "optimization" to always create new blocks
for the selection header.

Along the way, also made error reporting better in deserialization
by turning asserts into proper errors and add check of uses outside
of sinked structured control flow region blocks.

Reviewed By: Hardcode84

Differential Revision: https://reviews.llvm.org/D115582
2021-12-13 10:42:26 -05:00
Lei Zhang
731676b10d [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
2021-12-11 14:47:19 -05:00
Lei Zhang
3ed47bcc96 [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
2021-12-10 19:20:49 -05:00
Lei Zhang
222d7fc7f8 [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
2021-12-10 19:20:49 -05:00
River Riddle
0c7890c844 [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
2021-11-18 05:39:29 +00:00
KareemErgawy-TomTom
3fb384d50e [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
2021-03-06 16:05:31 +01:00
KareemErgawy-TomTom
88d5c4c2ee [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
2021-02-08 14:15:31 +01:00