This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][SPIRV] Add support for OpCopyMemory.
ClosedPublic

Authored by ergawy on Jun 23 2020, 7:43 AM.

Details

Summary

This patch add support for 'spv.CopyMemory'. The following changes are
introduced:

  • 'CopyMemory' op is added to SPIRVOps.td.
  • Custom parse and print methods are introduced.
  • A few Roundtripping tests are added.

Diff Detail

Event Timeline

ergawy created this revision.Jun 23 2020, 7:43 AM
ergawy updated this revision to Diff 272728.Jun 23 2020, 7:46 AM

Remove comments added during development.

ergawy marked an inline comment as done.Jun 23 2020, 7:51 AM
ergawy added inline comments.
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
223

Correct me if I am wrong, but I think we don't need a custom verifier here since in

static ParseResult parseCopyMemoryOp(OpAsmParser &parser,
                                     OperationState &state)

I did the needed verification that target and source types are compatible with each other.

ergawy marked an inline comment as done.Jun 23 2020, 7:54 AM
ergawy added inline comments.
mlir/test/Dialect/SPIRV/Serialization/memory-ops.mlir
60

Currently trying to come up with more tests. If you have any suggestions, please let me know :).

ergawy marked an inline comment as done.Jun 23 2020, 7:58 AM
ergawy added inline comments.
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
217–218

According to the spec: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpCopyMemory, the op supports up to 2 memory access operands. However, I still don't know how to model this in ODS.

rriddle added inline comments.Jun 23 2020, 12:04 PM
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
223

Please do not rely on verification done in the parser unless it is solely related to parsing. The verifier should *always* be complete. The majority of production systems(including MLIR itself via conversions) will never use the parser and instead construct IR directly. If the verification is in the parser and not here, the verification will never happen at all.

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

Where are you printing the attribute dictionary?

ergawy marked an inline comment as done.Jun 24 2020, 6:23 AM
ergawy added inline comments.
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
223

Thanks for your comment @rriddle . I wasn't aware of that point. I added a verifyCopyMemory function and currently trying to find a good test approach. As far as I understand:

  • Any test approach that starts with the textual representation won't really test all the possible paths inside the verifier function because we will have to go through the parser first. And, in the parser we have to resolve the SSA values based on the pointer types constructed from the element type attached to the op text for which some verification of type consistency has to be made.
  • Therefore, we have to directly construct the IR in order to test the verification logic thoroughly. One way I am considering is to introduce a new unit test under mlir/unittests/Dialect/SPIRV/.

I still need to figure out the pieces to construct the needed IR elements directly. But I just wanted to make sure that such approach would be suitable in that situation.

ergawy marked 4 inline comments as not done.Jun 24 2020, 6:41 AM
rriddle added inline comments.Jun 24 2020, 11:42 AM
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
223

Any test approach that starts with the textual representation won't really test all the possible paths inside the verifier function because we will have to go through the parser first.

This isn't a problem in MLIR, you can always use the generic parser form which won't go through any of the custom parser code paths. With that you could test any part of the verifier that you want.

ergawy updated this revision to Diff 273328.Jun 25 2020, 6:23 AM
  • Add verification function for OpCopyMemory.
  • Add tests for printing and verifying maa.
ergawy updated this revision to Diff 273332.Jun 25 2020, 6:31 AM
  • Rearrange code after rebase.
ergawy updated this revision to Diff 273336.Jun 25 2020, 6:37 AM
  • Rename template type arg.
ergawy marked 5 inline comments as done.Jun 25 2020, 6:39 AM
ergawy added inline comments.
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
223

Thank you! That's awesome. I added a few tests for verification with the generic syntax.

ergawy marked 3 inline comments as done.Jun 25 2020, 6:41 AM
ergawy added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
2823

I might be wrong, but isn't that done in line 2841?

ergawy marked an inline comment as done.Jun 25 2020, 7:17 AM
ergawy added inline comments.
mlir/include/mlir/Dialect/SPIRV/SPIRVOps.td
217–218

Is it ok to add a TODO for that issue and handle it with a later review? I am working on figuring out a way to do that at the moment. But I think it should ok to merge this review as is (after handling any further comments of course).

ergawy updated this revision to Diff 273358.Jun 25 2020, 7:51 AM
  • Print attr dictionary.
ergawy marked 2 inline comments as done.Jun 25 2020, 7:53 AM
ergawy added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
2823

Oh, I didn't get what you mean at first. Please, excuse the ignorance of the newbie 😄 .

antiagainst accepted this revision.Jun 26 2020, 6:37 AM

Awesome, this looks very clean. Thanks for the patch @ergawy!!

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

We don't need the leading : here. emitOpError will attach the message here with a leading 'xxx' op so we can write the message based on that assumption.

This revision is now accepted and ready to land.Jun 26 2020, 6:37 AM
antiagainst added inline comments.Jun 26 2020, 6:40 AM
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
2889

I'll take care of this before landing the patch.

ergawy marked an inline comment as done.Jun 26 2020, 6:56 AM
ergawy added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVOps.cpp
2889

Awesome, thank you!

This revision was automatically updated to reflect the committed changes.