We need to know how to generate correct SPIRV for cases like
OpConstant %int64 42 since the current parser will encode the 42 as a
32-bit value incorrectly.
This change is the first of a pair. This one tracks types, and makes
sure that OpConstant and OpSpecConstant are only ever called with
Integer or Float types, and OpSwitch is only called with integer
generating values.
Move the definition of spv_instruction_t to an internal
header file, since it now depends on C++ and is not
used by the external interface.
Use a std::vector<uint32_t> in spv_instruction_t
instead of a fixed size array.
Fixes dependencies among capabilities. (The table should store
the mask of capabilites, not the capability enum.)
Remove the old spot check test for capabilities of enums.
Implement some outstanding feedback from
Ic29c5a4a8178a62a5a1acad13d02f19cc1307097:
- use "token" instead of "word" when referring to assembly text
- specify how the numbers are parsed
Add a test for negative numbers.
Operand class enum values not used in the syntax table:
- Image channel order: only used to describe a return value
- Image channel type: only used to describe a return value
- "Image operands": used to make a section in the spec
to describe values used to construct an optional image id,
but does not itself appear in the syntax table.
Removes some TODOs from opcode.cpp.
All uses of OptionalLiteral by the SPIR-V spec are used
for literal numbers.
Also rename:
- SPV_OPERAND_TYPE_OPTIONAL_LITERAL to
SPV_OPERAND_TYPE_OPTIONAL_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_VARIABLE_LITERAL to
SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_VARIABLE_LITERAL_ID to
SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER_ID.
- SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL to
SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_NUMBER.
- SPV_OPERAND_TYPE_LITERAL_IN_OPTIONAL_TUPLE to
SPV_OPERAND_TYPE_LITERAL_NUMBER_IN_OPTIONAL_TUPLE.
Many instructions added and a few changed structure.
Workarounds:
- Some operands can be enabled by either one of two
capabilities. The spv_operand_desc_t does not handle that
now. For now just select the first one.
Fixes to tests:
- OpLoopMerge now takes a mandatory continue target.
- OpTypePipe drops the type argument. Pipes are opaque.
- OpLine no longer takes a target ID argument.
The ID validator was fixed the OpLine and OpTypePipe
changes. Those were the only ID validator tests affected.
The patch to the spec doc generator was updated so it handles
the two-capability case, even if in an hacky way.
Also removed un-necessary heap-allocation of spv_named_id_table.
This removed the necessity to expose a function to create/destroy it
and simplified the interface.
If a memory mask operand is present, it is a mask. The mask appears
only once, so just use SPV_OPERAND_TYPE_OPTIONAL_MEMORY_MASK.
The "variable literals" aspect comes into play as follows: if the
Aligned bit is set in the mask, then the parser will be made to
expect the alignment value as a literal number operand that follows
the mask. That is done through mask operand expansion.
Properly support a memory access mask with a combination
of bits, including the Aligned bit. When the Aligned bit is
set, the parser should expect an alignment value literal operand.
For example, support combining mask enums with "|",
such as "NotNaN|AllowRecip" for the fast math mode.
This is supported for mask values that don't modify the
expected operand pattern:
- fast math mode
- function control
- loop control
- selection control
TODO: disassembler support to print them as mask expressions.