Fixed an issue where some of the tests were testing
the wrong word with the wrong operation. (| != ||).
Coalesced the many versions of EnumCase into one.
Added a get_value() to EnumCase to convert to a uint32_t.
Replaces ASSERT_TRUE(pointer), with ASSERT_NE(nullptr, pointer),
so that we do not do implicit pointer->bool conversion.
Removed const from some test structs since gtest needs to be
able to swap them.
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.
You can't use names from 3.12 Image Channel Order and
3.13 Image Channel Data Type since in the intstruction grammar,
they are only used as return values, but never named arguments
to instructions.
This is in preparation for coming tests that will also
use the templated EnumCase instead of making their
own structs.
Also reformat AccessQualifier test.
Add a new operand type SPV_OPERAND_TYPE_MULTIWORD_LITERAL_NUMBER
to represent those operands that can expand into multiple words.
Now only OpConstant and OpSpecConstant have such kind of operand.
You can't use a named enumerant if it's only meaningful
in an operand supplied as an ID to a target instruction.
The place where you'd use the name is something like an
OpConstant, but there's not enough context to bring those
names into scope, unless you're willing to tolerate
potential collisions.
Occurs for the names in:
- 3.25 Memory Semantics
- 3.27 Scope ID
- 3.29 Kernel Enqueue Flags
- 3.30 Kernel Profiling Info
