The crash was a result of the accesses in lines 512 and 1176. If the kernel was not present in the map, a default initialized entry was created.
Fixes SWDEV-404491
Differential D154946
[AMDGPULowerModuleLDSPass] Kernels do not always have entries in KernelToReplacement map jmmartinez on Jul 11 2023, 3:52 AM. Authored by
Details
The crash was a result of the accesses in lines 512 and 1176. If the kernel was not present in the map, a default initialized entry was created. Fixes SWDEV-404491
Diff Detail
Event TimelineComment Actions Thanks for the patch! On reading through I think there's something more fundamentally broken here. Please could you hold fire on this for a moment while I dig through it? There's some refactoring in line which seems worth having asap - the extra const, the spurious copy deleted - would you prefer I post a diff with those parts pulled out or you post one for me to accept?
Comment Actions No problem! I will move it into a separate patch.
Comment Actions OK, I think I've got the root cause. The slow path lowering for normal variables is a table lookup indexed by kernel id, which is an integer assigned somewhat arbitrarily and later made available through the lds intrinsic (involves dedicating a sgpr to the i32 value). The lowering for dynamic variables is a table lookup indexed by the same kernel id because I didn't think it was worth burning a second sgpr on it. The pass successfully assigns integers to kernels that use either of these variables. assignLDSKernelIDToEachKernel takes two sets, combines them, sorts the result. Where it then goes wrong is the lookup table construction assumes every kernel with an index will have a corresponding element, which was true before dynamic variable lowering was introduced. Now however, if a kernel uses dynamic variables and no table lookup static ones, it'll have an assigned index but the corresponding table entry needs to be poison. Lowerdynamicldsvariables handles this correctly because it was written at the same time as breaking that invariant. Right fix is going to involve poison at some positions in the lookup table, probably similarly to buildLookupTable. Likely to look like a hybrid of this patch and D154972. |
I don't follow this chunk. Previously count != 0 followed by lookup. New find != end followed by using the previous value. Is there a functional change I'm missing here?