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