[clang] [llvm] [HLSL][SPIRV][DXIL] Implement `dot4add_i8packed` intrinsic (PR #113623)

Steven Perron via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 5 06:27:11 PST 2024


s-perron wrote:

> Regarding the comments about differentiating between `OpSDot/DotProduct` and `OpSDotKHR/DotProductKHR`:
> 
> I agree that these are different ops/capabilities in the SPIR-V spec.
> 
> However from a quick attempt to implement this, I found that since the Capabilities share the same bit value of (`6016, 6017,...`), we do not have a way to differentiate between these capabilities when checking requirements and adding available capabilities. This is because `SPIRV::Capability::DotProduct == SPIRV::Capability::DotProductKHR = 6019`.
> 
> I think implementing a way to differentiate capabilities that have the same value is out of scope for this pr. So I would propose that we file a follow-up issue to deal with that and either:
> 
> * Merge as-is
> * Remove the extension based changes from this pr, so only use `OpSDot` and the `DotProduct` capability when we have a version that fits
> * Remove the version based changes from this pr, so only use `OpSDotKHR` and the `DotProductKHR` capability when the extension is provided
> * Remove both optimized versions and only lower to the expansion
> 
> WDYT?

I'll check with the authors of spirv-as and spirv-dis, but here are my thoughts.

This distinction makes no difference in the binary format, which is what is defined by the SPIR-V specification. The SPIR-V specification does not define the human readable format. See https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_example.

The textual format ouput by glslang by default is actually very different. It is just that the format used by spirv tools happens to have one. If we use Spirv-Tools as the guide, then we can use either one interchangeably. Here are two examples:

1. Spirv-dis will always output the non-KHR string. `OpSDotKHR` is used initially, but when disassembled it uses `OpSDot`: https://godbolt.org/z/bPf67vnss
2. Spirv-as accepts the non-KHR string: https://godbolt.org/z/Mf8b9x8dc

I think it is fair for the llvm backend to do the same. The only time people will have a problem is when they use llvm to generate the asm, and try to generate a binary using an older spirv-as. That is easily fixed by generating the binary in llvm.

https://github.com/llvm/llvm-project/pull/113623


More information about the cfe-commits mailing list