[clang] [llvm] [SPIRV] Add support for the `SPV_EXT_long_vector` extension (PR #210279)

Alex Voicu via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 17 08:36:23 PDT 2026


================
@@ -349,13 +347,30 @@ SPIRVGlobalRegistry::getOpTypeVector(uint32_t NumElems, SPIRVTypeInst ElemType,
 
   return createConstOrTypeAtFunctionEntry(
       MIRBuilder, [&](MachineIRBuilder &MIRBuilder) {
-        return MIRBuilder.buildInstr(SPIRV::OpTypeVector)
+        return MIRBuilder
+            .buildInstr(IsLongVector ? SPIRV::OpTypeVectorIdEXT
+                                     : SPIRV::OpTypeVector)
             .addDef(createTypeVReg(MIRBuilder))
             .addUse(getSPIRVTypeID(ElemType))
             .addImm(NumElems);
       });
 }
 
+SPIRVTypeInst
+SPIRVGlobalRegistry::getOpTypeVector(uint32_t NumElems, SPIRVTypeInst ElemType,
+                                     MachineIRBuilder &MIRBuilder) {
+  assert(NumElems >= 2 && "SPIR-V OpTypeVector requires at least 2 components");
+  return getOpTypeVectorImpl(NumElems, ElemType, MIRBuilder);
+}
+
+SPIRVTypeInst SPIRVGlobalRegistry::getOpTypeVectorIdEXT(
+    uint32_t NumElems, SPIRVTypeInst ElemType, MachineIRBuilder &MIRBuilder) {
+  assert((NumElems < 2 || NumElems > 16 ||
+          (NumElems != 3 && NumElems != 4 && NumElems != 8)) &&
+         "SPIR-V OpTypeVectorIdExt should only be used for extended vectors");
----------------
AlexVlx wrote:

Yes, but, more specifically, the implementation is as it is because `OpTypeVector` is core. It doesn't seem beneficial to pivot towards all vectors being `vectorIdEXT`'s if the extension is enabled, it is perfectly possible to not need it and then we get a simpler / more compatible module.

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


More information about the cfe-commits mailing list