Duplicate non-aggregate type declarations are not allowed about spirv-llvm-translator HOT 6 CLOSED

okay, I was able to track down the issue a bit more. The bug is inside LLVMToSPIRV::transType.

What happens is basically this:

1. SPIRV::LLVMToSPIRV::transType called on "void (global struct Node* out, global struct Node* in)"
2. SPIRV::LLVMToSPIRV::transType called on "global struct Node*"
3. SPIRV::LLVMToSPIRV::transType called on "struct Node"
4. SPIRV::LLVMToSPIRV::transType called on "global struct Node*"
5. SPIRV::LLVMToSPIRV::transType called on "struct Node"

in 5. the call chain gets broken because "struct Node" already exists inside TypeMap, but the call chain has to be aborted in the 4th step already, otherwise we end up with two "global struct Node*" pointer types while parsing the a struct with members pointing to itself.

from spirv-llvm-translator.

some tests which also generated invalid SPIRV like this:

• transcoding/RecursiveType.ll
• transcoding/OpImageQuerySize.ll

from spirv-llvm-translator.

Now after reading the SPIRV specification more carefully, especially section 2.8, I came to the conclusion that this should be a bug within spirv-val.

Section 2.8:
[...] Pointer types are also allowed to have multiple ids for the same opcode and operands, to allow for differing decorations (e.g., Volatile) or different decoration values (e.g., different Array Stride values for the ArrayStride). [...]

from spirv-llvm-translator.

Filed bug against spirv-val: KhronosGroup/SPIRV-Tools#1577

from spirv-llvm-translator.

Okay, so for this to be valid SPIR-V code we either need the SPV_KHR_variable_pointers extension or have to use SPIR-V 1.3 whenever we end up with multiple OpTypePointer declarations being identical.

@AlexeySotkin Any suggestion what is the prefered thing to do here?

See KhronosGroup/SPIRV-Tools#1580 for the upstream fix in spirv-val

from spirv-llvm-translator.

It does look like following to patches are addressing this issue:

commit 8a0235a239f34a19136eafd88c7f515537bab40a
Author: Viktoria Maximova <[email protected]>
Date:   Tue Mar 22 12:37:49 2022 +0300

    Support complex recursive types that use an array of pointers (#1434)

    The use of pointer arrays inside the recursive type leads to the SPIR-V IR, where
    the TypePointer is declared after TypeArray. In turn, TypeArray can't handle the
    unknown element type, because the info from TypeForwardPointer is not used.

    Now the translator stores forward declared IDs to use them in backward
    translation. It actually means that the translator "knows" about the type but it
    would be handled later.

commit 5594d7c112edb21508526c6a3b0068df3a4201c6
Author: Alexey Sotkin <[email protected]>
Date:   Thu Mar 4 17:49:10 2021 +0300

    Redesign handling of forward pointers

    In some cases the current implementation doesn't create forward pointers
    when they are required. New approach is to create forward pointers
    during sorting of the type instructions.

    Signed-off-by: Alexey Sotkin <[email protected]>

and this patch proves, that the issue is fixed:

commit 1a800a0f65a231b1e0b5aedf0d99b0230563639b
Author: Sven van Haastregt <[email protected]>
Date:   Tue Jun 29 14:33:50 2021 +0100

    Run spirv-val for more tests

hence closing it

from spirv-llvm-translator.