Remapper: handle embedded opcode in OpSpecConstantOp

OpSpecConstantOp contains an embedded opcode which is given as a literal
argument to the OpSpecConstantOp.  The subsequent arguments are as the
embedded op would expect, which may be a mixture of IDs and literals.  This
adds support for that to the remapper binary parser.  Upon seeing such an
embedded op, the parser flips over to parsing the argument list as
appropriate for that opcode.

Fixes #882.
This commit is contained in:
LoopDawg
2017-05-18 16:13:04 -06:00
parent 24e895b4a3
commit 65c2eed65d
3 changed files with 47 additions and 1 deletions

View File

@@ -464,8 +464,8 @@ namespace spv {
{
const auto instructionStart = word;
const unsigned wordCount = asWordCount(instructionStart);
const spv::Op opCode = asOpCode(instructionStart);
const int nextInst = word++ + wordCount;
spv::Op opCode = asOpCode(instructionStart);
if (nextInst > int(spv.size()))
error("spir instruction terminated too early");
@@ -506,6 +506,18 @@ namespace spv {
// Store IDs from instruction in our map
for (int op = 0; numOperands > 0; ++op, --numOperands) {
// SpecConstantOp is special: it includes the operands of another opcode which is
// given as a literal in the 3rd word. We will switch over to pretending that the
// opcode being processed is the literal opcode value of the SpecConstantOp. See the
// SPIRV spec for details. This way we will handle IDs and literals as appropriate for
// the embedded op.
if (opCode == spv::OpSpecConstantOp) {
if (op == 0) {
opCode = asOpCode(word++); // this is the opcode embedded in the SpecConstantOp.
--numOperands;
}
}
switch (spv::InstructionDesc[opCode].operands.getClass(op)) {
case spv::OperandId:
case spv::OperandScope: