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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
