Expose more of the utility functionality about spirv-tools HOT 4 CLOSED

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.

from spirv-tools.

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.

from spirv-tools.

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.

from spirv-tools.

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

from spirv-tools.