[llvm] [SPIRV] Do not use OpTypeRuntimeArray in Kernel env. (PR #149522)

Steven Perron via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 21 07:37:54 PDT 2025


================
@@ -828,9 +828,11 @@ SPIRVType *SPIRVGlobalRegistry::getOpTypeArray(uint32_t NumElems,
          "Invalid array element type");
   SPIRVType *SpvTypeInt32 = getOrCreateSPIRVIntegerType(32, MIRBuilder);
   SPIRVType *ArrayType = nullptr;
-  if (NumElems != 0) {
-    Register NumElementsVReg =
-        buildConstantInt(NumElems, MIRBuilder, SpvTypeInt32, EmitIR);
+  const SPIRVSubtarget &ST =
+      cast<SPIRVSubtarget>(MIRBuilder.getMF().getSubtarget());
+  if (NumElems != 0 || !ST.isShader()) {
+    Register NumElementsVReg = buildConstantInt(
+        NumElems ? NumElems : 1, MIRBuilder, SpvTypeInt32, EmitIR);
----------------
s-perron wrote:

The issue is not the access to `i`, but the offset of `b`.

The issue is that when the code is not optimized, accesses to `b` are done through the struct whose first element `i` is an array of size 1. So `b` is considered to be at offset 4 in the struct. Is that right? See https://godbolt.org/z/37vbjGP3r. I removed the UB.

However, if the code is optimized, the optimizer modifies the GEP to access `b` starting at offset `0` in the struct. From the optimizer's perspective this is correct because `i` is an array of size 0. See https://godbolt.org/z/fj1hfdeqo.

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


More information about the llvm-commits mailing list