[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