Expose more of the utility functionality

[daseyb]

There is a lot of useful functionality, especially in opcode.h which is currently not exposed via the libspirv.h header.

I'm mostly looking for an easy way to get instruction metadata (e.g. names of instructions and types of operands). I'm generating this myself from the HTML spec at https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html right now, but this is cumbersome to update since the HTML formatting tends to change slightly between versions.

One thing that I found particularly useful while working on https://github.com/bonus2113/otherside/ was having a type for each instruction (see https://github.com/bonus2113/otherside/blob/master/src/shared/lookups_gen.h for an example) which allowed me to easily access operands by name, but that might be out of scope for this project.

[dneto0]

I agree, we definitely want to expose some things used internally by the assembler and disassembler:

• the string name for an opcode, or an operand type.
• the opposite lookup: go from string to operand, opcode.
  I'd like to make these calls on the context object. I don't want to expose the internal tables because that's an implementation detail. I'd like to be able to optimize their construction and access.

The type-per instruction is more interesting. Many instructions are can take a variable number of arguments. Sometimes they have an optional operand, or more than one optional operand, or a sequence of zero or more operands or pairs of operands (like OpSwitch).

The Image Operands are very interesting (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_a_id_image_operands_a_image_operands)
A single word provides a bitmask which then determines what other operands are to be expected next.

The solution we chose in the binary parser and the assembler was to maintain a queue of operand-types to expect (see https://github.com/KhronosGroup/SPIRV-Tools/blob/master/source/binary.cpp#L309). And the opcode and operand tables have small arrays of operand types encoding "what else do I expect after I see this opcode/operand".

In summary there is no fixed "instruction type". The closest we come is the spv_parsed_instruction_t
https://github.com/KhronosGroup/SPIRV-Tools/blob/master/include/libspirv/libspirv.h#L289
which encodes how a particular instruction instance breaks down into operand words.

Think about this and tell me if you think that will meet your needs.

[daseyb]

Thanks for the explanation! I hadn't run into the issue with the Image Operands yet.

I still think that typed instructions are something that's worth exploring since it works well for a majority of instructions and has been very convenient for me so far. Though I see how a general solution might be difficult to implement.

I'll let you know if I come up with anything usable.

[dneto0]

I'm taking this issue. I'd like to drive its necessity by adding example uses of the API to dump information about a binary, e.g. what capabilities are declared by a given SPIR-V module.

[dj2]

This seems like it's satisfied by the spirv-headers repo now, is that the case? Can this be closed?