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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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
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
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. |
mlir/lib/Dialect/SPIRV/SPIRVDialect.cpp | ||
---|---|---|
679 | nit: attribute -> attributes? |
mlir/test/Dialect/SPIRV/target-and-abi.mlir | ||
---|---|---|
55 | nit: attribute-> attributes? |
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
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. :) |
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). |
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. :) |
clang-tidy: error: 'mlir/IR/Dialect.h' file not found [clang-diagnostic-error]