Closed vmaksimo closed 5 months ago
Would it be worth adding a SPIR-V-friendly-IR test, to have the newly added code covered?
@svenvh it looks like yes, but unfortunately I wasn't able to come up with the LLVM IR where types will be translated to "not equal but logically matched" types in SPIR-V. Otherwise spirv-val will fail which will stop us from testing reverse translation.
So, my guess is that we can proceed without test till the moment it'll be an issue for users or we'll be able to do a proper translation.
@svenvh it looks like yes, but unfortunately I wasn't able to come up with the LLVM IR where types will be translated to "not equal but logically matched" types in SPIR-V.
I've been looking a bit into the history of OpCopyLogical
; it seems the motivation came from GLSL: https://github.com/KhronosGroup/glslang/issues/304 so I'm not even sure how much we'll see this instruction in the SPIR-V Kernel
domain. But it's not gated by any capability, so the translator will have to support it.
Maybe we can just test that OpCopyLogical
is consumed with a .spvasm
file (which would be somewhat similar to the SPIR-V provided in the glslang issue: declare two distinct struct types that have the same member type and then use OpCopyLogical
to copy between two variables of both struct types).
There is no mapping to LLVM instructions, so it can be used only via SPIR-V friendly translation.
This addresses p1. of #2460