| Issue |
177806
|
| Summary |
[SPIRV] Generating nested structs which is causing exceptions in spirv-cross
|
| Labels |
HLSL,
backend:SPIR-V
|
| Assignees |
|
| Reporter |
farzonl
|
## Repro case
HLSL to SPIRV (via clang-dxc): https://hlsl.godbolt.org/z/67MrYM7qT
SPIRV to MSL (via spirv-cross): https://godbolt.org/z/bs5vqfrYT
## Exception triggered
https://github.com/KhronosGroup/SPIRV-Cross/blob/a0fba56c34a6700f1724bf9b751da5b488a3775c/spirv_msl.cpp#L5217
## Expected result
HLSL to SPIRV (via dxc): https://hlsl.godbolt.org/z/9xWGjsK5c
SPIRV to MSL (via spirv-cross): https://godbolt.org/z/qxTjeafYv
## Theory as to issue:
The problem seems to be ths chain of instructions causing a nested struct chain involving an 8-bit member.
```spirv
%9 = OpTypeInt 8 0 // (8-bit uint)
%10 = OpTypeStruct %3 %9 // (struct { uint32; uint8; })
%16 = OpTypeArray %10 %13 // (array of that struct)
%18 = OpTypeStruct %16 %9 %14 // (struct contains the array-of-%10, plus another uint8, plus an array of uint4)
%19 = OpTypeStruct %18 // (wrapper struct)
...
%54 = OpVariable %20 Uniform where %20 = OpTypePointer Uniform %19
```
It looks like spirv-cross is repack the struct making it nested:
```spirv
%19 = OpTypeStruct %18 // (and, transitively, %54 being a Uniform pointer to %19)
```
Because `%18` is now a member of another struct (`%19`), any repacking needed inside `%18` (driven here by the 8-bit members/packing) becomes illegal per the SPIRV-Cross’ exception mentioned above. The underlying reason repacking is being considered is the presence of `%9` (8-bit) inside uniform-buffer-relevant structs (`%10`, `%18`).
It seems like DXC has no 8-bit types so that maps cleanly to MSL without needing the repacking.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
