This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][SPIRV] Add initial support for OpSpecConstantComposite.
ClosedPublic

Authored by ergawy on Sep 30 2020, 7:06 AM.

Details

Summary

This commit adds support to SPIR-V's composite specialization constants.
These are specialization constants which are composed of other spec
constants (whehter scalar or composite), regular constatns, or undef
values.

This commit adds support for parsing, printing, verification, and
(De)serialization.

A few TODOs are still in order:

  • Supporting more types of constituents; currently, only scalar spec constatns are supported.
  • Extending spv._reference_of to support composite spec constatns.

Diff Detail

Event Timeline

ergawy created this revision.Sep 30 2020, 7:06 AM
ergawy requested review of this revision.Sep 30 2020, 7:06 AM
ergawy edited the summary of this revision. (Show Details)Sep 30 2020, 7:07 AM
antiagainst requested changes to this revision.Oct 1 2020, 8:41 AM
antiagainst added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
3303

OpSpecConstantComposite is different than OpConstantComposite. I don't think composite spec constant for cooperative matrix is well spec'd: https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/NV/SPV_NV_cooperative_matrix.asciidoc#3327-constant-creation-instructions. Let's just emit error if the result type is a cooperative matrix util the spec is clarified.

3331

s/auto/char/

3352

We don't need to call into the verifier in the parser. The parser only need to verify things that are necessary for valid parsing. The rest should be left to the normal validator.

mlir/test/Dialect/SPIRV/structure-ops.mlir
716

Let's emit error for such cases. :) It is not well spec'd at the moment.

This revision now requires changes to proceed.Oct 1 2020, 8:41 AM
ergawy updated this revision to Diff 295759.Oct 2 2020, 1:53 AM
  • Handle review comments.
ergawy marked 4 inline comments as done.Oct 2 2020, 1:56 AM

@antiagainst , thanks a lot for the prompt review.

mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
3352

I moved the verification logic out of the parser. But, in general, shouldn't we verify as much as we can in the parser because we would then have the location info and therefore error reporting would be more localized? This is the main reason I maintained as much verification in the parser as can be done and duplicated that in the verifier with additional tests that cannot be done during parsing.

ergawy marked an inline comment as done.Oct 2 2020, 2:25 AM
ergawy updated this revision to Diff 295767.Oct 2 2020, 2:25 AM
  • Update Op docs.
ergawy updated this revision to Diff 295805.Oct 2 2020, 5:42 AM
  • Rebase (testing how stacked reviews work).
antiagainst accepted this revision.Oct 2 2020, 11:41 AM
antiagainst added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
3352

I might not understand you question properly but the op itself already captures location information so when the verifier sees error it can relate back to the source.

In general verifier is enabled for all the op instances, whether created via C++ API or parsing the canonical/custom assembly. There is no need to duplicate the verification logic in custom parser. It also means better separation of concerns.

This revision is now accepted and ready to land.Oct 2 2020, 11:41 AM