This is an archive of the discontinued LLVM Phabricator instance.

[mlir][spirv] Fix shader ABI attribute prefix and add verification
ClosedPublic

Authored by antiagainst on Jan 1 2020, 7:48 PM.

Details

Summary

This commit fixes shader ABI attributes to use spv. as the prefix
so that they match the dialect's namespace. This enables use to
add verification hooks in the SPIR-V dialect to verify them.

Diff Detail

Event Timeline

antiagainst created this revision.Jan 1 2020, 7:48 PM

Unit tests: pass. 61169 tests passed, 0 failed and 728 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Add more tests

Unit tests: pass. 61169 tests passed, 0 failed and 728 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

mravishankar requested changes to this revision.Jan 2 2020, 10:09 AM

Thanks for fixing the naming!

mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp
664

"verifyRegionArgResultAttribute" is misleading. What is intended by ArgResult? How about just "verifyRegionArgAttribute"

696

I am not sure it is well defined to have a InterfaceVarABIAttr for the result. So far the GPU to SPIR-V lowering assumes that entry point functions have no return values, and the LowerABIAttributesPass does not handle ABI attributes on the results. I tried to add that, but wasnt sure about the semantics there. So better to not handle it, and maybe error out when such attribute is specified on the result.

This revision now requires changes to proceed.Jan 2 2020, 10:09 AM
kiszk added a subscriber: kiszk.Jan 2 2020, 10:46 AM
kiszk added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp
679

nit: attribute -> attributes?

kiszk added inline comments.Jan 2 2020, 11:43 AM
mlir/test/Dialect/SPIRV/target-and-abi.mlir
55

nit: attribute-> attributes?
Same comments to other places

antiagainst marked 4 inline comments as done.

Address comments

Unit tests: pass. 61169 tests passed, 0 failed and 728 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

antiagainst added inline comments.Jan 2 2020, 1:11 PM
mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp
664

Changed to verifyRegionAttribute and added comments to avoid the confusion.

696

What are the problems you see for attaching InterfaceVarABIAttr to a result? Isn't the semantics of it a write-only buffer?

In the verification code implemented by this CL, I'm intentionally not checking which op the attribute is attached to so that we can allow "carrying over" these attributes on some intermediate state in the lowering process. (For example somebody might want to create an intermediate function op of some sort maybe.) So the verification here only focuses on the attributes themselves; not really paying attention to the op or region arg/result index/position, etc. I get your points that we are not supporting InterfaceVarABIAttr in GPU lowering yet but this still seems a step forward that is nice to have: previously we don't verify these attributes at all, now we at least make sure they are correct internally. :)

mravishankar added inline comments.Jan 2 2020, 2:45 PM
mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp
696

What would the function look like

func(%arg0 : memref<..>) -> memref<..> { ... }

This suggests that you are "returning" a memref, which makes ownership of that memref tricky to define. You could say that the lowering will convert this function into

func(%arg0 : memref<...>, %arg1 : memref<...>) {...}

and then say %arg1 is for the result. All this needs to be handled in the LowerABIAttributesPass. I was waiting for having a realistic use case for this. Currently when lowering from GPU dialect to SPIR-V, the entry function has void return type. So would rather have the verifier return error on this (cause its not implemented).

antiagainst marked 2 inline comments as done.Jan 2 2020, 4:39 PM
antiagainst added inline comments.
mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp
696

Right, it depends on the definition of the op and its semantics. It might not make sense for func given that we have a relatively clear definition and understanding. I could have my funky op that uses results for some other purposes. Not advocating that we should intentionally support such cases; it's just that IMO that is a separate concern than verifying the attribute itself: it's more of resulting from the op's semantics than the spv.* attributes' semantics.

This is just another incarnation of the open-vs-closed trade-off we are facing. :) Typically I'd be very worried if being open means we can have many unexpected ways to break. Then I'd prefer to enumerate what we have at hand and support them explicitly and go from there to extend as needed. But for this one it seems it's not gonna bite us that much (and whatever unexpected places it gets attached to have some minimal verification at least). So I'd think a little openness does not hurt that much. :)

mravishankar accepted this revision.Jan 2 2020, 4:56 PM
This revision is now accepted and ready to land.Jan 2 2020, 4:56 PM
This revision was automatically updated to reflect the committed changes.