2016-01-07 18:44:22 +00:00
|
|
|
// Copyright (c) 2015-2016 The Khronos Group Inc.
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
2015-05-22 17:26:19 +00:00
|
|
|
|
|
|
|
#include "operand.h"
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include <string.h>
|
2017-06-27 23:28:22 +00:00
|
|
|
#include <algorithm>
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2016-04-27 20:47:13 +00:00
|
|
|
#include "macro.h"
|
2016-01-06 18:08:39 +00:00
|
|
|
|
2018-02-09 19:29:02 +00:00
|
|
|
// For now, assume unified1 contains up to SPIR-V 1.3 and no later
|
|
|
|
// SPIR-V version.
|
|
|
|
// TODO(dneto): Make one set of tables, but with version tags on a
|
|
|
|
// per-item basis. https://github.com/KhronosGroup/SPIRV-Tools/issues/1195
|
|
|
|
|
|
|
|
#include "operand.kinds-unified1.inc"
|
2017-09-21 21:24:57 +00:00
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
static const spv_operand_table_t kOperandTable = {
|
|
|
|
ARRAY_SIZE(pygen_variable_OperandInfoTable),
|
|
|
|
pygen_variable_OperandInfoTable};
|
2017-10-25 16:15:51 +00:00
|
|
|
|
|
|
|
spv_result_t spvOperandTableGet(spv_operand_table* pOperandTable,
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_target_env) {
|
2017-10-25 16:15:51 +00:00
|
|
|
if (!pOperandTable) return SPV_ERROR_INVALID_POINTER;
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
*pOperandTable = &kOperandTable;
|
|
|
|
return SPV_SUCCESS;
|
2015-05-22 17:26:19 +00:00
|
|
|
}
|
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_result_t spvOperandTableNameLookup(spv_target_env env,
|
|
|
|
const spv_operand_table table,
|
2015-05-22 17:26:19 +00:00
|
|
|
const spv_operand_type_t type,
|
2015-09-16 20:42:56 +00:00
|
|
|
const char* name,
|
|
|
|
const size_t nameLength,
|
|
|
|
spv_operand_desc* pEntry) {
|
2015-09-11 18:31:27 +00:00
|
|
|
if (!table) return SPV_ERROR_INVALID_TABLE;
|
|
|
|
if (!name || !pEntry) return SPV_ERROR_INVALID_POINTER;
|
2015-05-22 17:26:19 +00:00
|
|
|
|
|
|
|
for (uint64_t typeIndex = 0; typeIndex < table->count; ++typeIndex) {
|
2016-04-27 20:47:13 +00:00
|
|
|
const auto& group = table->types[typeIndex];
|
|
|
|
if (type != group.type) continue;
|
|
|
|
for (uint64_t index = 0; index < group.count; ++index) {
|
|
|
|
const auto& entry = group.entries[index];
|
2018-03-14 17:06:18 +00:00
|
|
|
// We considers the current operand as available as long as
|
|
|
|
// 1. The target environment satisfies the minimal requirement of the
|
|
|
|
// operand; or
|
|
|
|
// 2. There is at least one extension enabling this operand.
|
|
|
|
//
|
|
|
|
// Note that the second rule assumes the extension enabling this operand
|
|
|
|
// is indeed requested in the SPIR-V code; checking that should be
|
|
|
|
// validator's work.
|
|
|
|
if ((static_cast<uint32_t>(env) >= entry.minVersion ||
|
|
|
|
entry.numExtensions > 0u) &&
|
|
|
|
nameLength == strlen(entry.name) &&
|
2016-04-27 20:47:13 +00:00
|
|
|
!strncmp(entry.name, name, nameLength)) {
|
|
|
|
*pEntry = &entry;
|
|
|
|
return SPV_SUCCESS;
|
2015-05-22 17:26:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return SPV_ERROR_INVALID_LOOKUP;
|
|
|
|
}
|
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_result_t spvOperandTableValueLookup(spv_target_env env,
|
|
|
|
const spv_operand_table table,
|
2015-05-22 17:26:19 +00:00
|
|
|
const spv_operand_type_t type,
|
|
|
|
const uint32_t value,
|
2015-09-29 14:56:32 +00:00
|
|
|
spv_operand_desc* pEntry) {
|
2015-09-11 18:31:27 +00:00
|
|
|
if (!table) return SPV_ERROR_INVALID_TABLE;
|
|
|
|
if (!pEntry) return SPV_ERROR_INVALID_POINTER;
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_operand_desc_t needle = {"", value, 0, nullptr, 0, nullptr, {}, ~0u};
|
|
|
|
|
|
|
|
auto comp = [](const spv_operand_desc_t& lhs, const spv_operand_desc_t& rhs) {
|
|
|
|
return lhs.value < rhs.value;
|
|
|
|
};
|
|
|
|
|
2015-05-22 17:26:19 +00:00
|
|
|
for (uint64_t typeIndex = 0; typeIndex < table->count; ++typeIndex) {
|
2016-04-27 20:47:13 +00:00
|
|
|
const auto& group = table->types[typeIndex];
|
|
|
|
if (type != group.type) continue;
|
2018-03-14 17:06:18 +00:00
|
|
|
|
|
|
|
const auto beg = group.entries;
|
|
|
|
const auto end = group.entries + group.count;
|
|
|
|
|
|
|
|
// We need to loop here because there can exist multiple symbols for the
|
|
|
|
// same operand value, and they can be introduced in different target
|
|
|
|
// environments, which means they can have different minimal version
|
|
|
|
// requirements. For example, SubgroupEqMaskKHR can exist in any SPIR-V
|
|
|
|
// version as long as the SPV_KHR_shader_ballot extension is there; but
|
|
|
|
// starting from SPIR-V 1.3, SubgroupEqMask, which has the same numeric
|
|
|
|
// value as SubgroupEqMaskKHR, is available in core SPIR-V without extension
|
|
|
|
// requirements.
|
|
|
|
// Assumes the underlying table is already sorted ascendingly according to
|
|
|
|
// opcode value.
|
|
|
|
for (auto it = std::lower_bound(beg, end, needle, comp);
|
|
|
|
it != end && it->value == value; ++it) {
|
|
|
|
// We considers the current operand as available as long as
|
|
|
|
// 1. The target environment satisfies the minimal requirement of the
|
|
|
|
// operand; or
|
|
|
|
// 2. There is at least one extension enabling this operand.
|
|
|
|
//
|
|
|
|
// Note that the second rule assumes the extension enabling this operand
|
|
|
|
// is indeed requested in the SPIR-V code; checking that should be
|
|
|
|
// validator's work.
|
|
|
|
if (static_cast<uint32_t>(env) >= it->minVersion ||
|
|
|
|
it->numExtensions > 0u) {
|
|
|
|
*pEntry = it;
|
2016-04-27 20:47:13 +00:00
|
|
|
return SPV_SUCCESS;
|
2015-05-22 17:26:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return SPV_ERROR_INVALID_LOOKUP;
|
|
|
|
}
|
|
|
|
|
2015-09-29 14:56:32 +00:00
|
|
|
const char* spvOperandTypeStr(spv_operand_type_t type) {
|
2015-05-22 17:26:19 +00:00
|
|
|
switch (type) {
|
|
|
|
case SPV_OPERAND_TYPE_ID:
|
2015-09-14 21:07:11 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_ID:
|
|
|
|
return "ID";
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_TYPE_ID:
|
|
|
|
return "type ID";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_RESULT_ID:
|
|
|
|
return "result ID";
|
2015-10-14 21:02:39 +00:00
|
|
|
case SPV_OPERAND_TYPE_LITERAL_INTEGER:
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_LITERAL_INTEGER:
|
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_LITERAL_NUMBER:
|
2015-05-22 17:26:19 +00:00
|
|
|
return "literal number";
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_TYPED_LITERAL_INTEGER:
|
|
|
|
return "possibly multi-word literal integer";
|
|
|
|
case SPV_OPERAND_TYPE_TYPED_LITERAL_NUMBER:
|
|
|
|
return "possibly multi-word literal number";
|
|
|
|
case SPV_OPERAND_TYPE_EXTENSION_INSTRUCTION_NUMBER:
|
|
|
|
return "extension instruction number";
|
2015-11-11 06:56:49 +00:00
|
|
|
case SPV_OPERAND_TYPE_SPEC_CONSTANT_OP_NUMBER:
|
|
|
|
return "OpSpecConstantOp opcode";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_LITERAL_STRING:
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_LITERAL_STRING:
|
2015-05-22 17:26:19 +00:00
|
|
|
return "literal string";
|
|
|
|
case SPV_OPERAND_TYPE_SOURCE_LANGUAGE:
|
2015-10-09 15:06:10 +00:00
|
|
|
return "source language";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_EXECUTION_MODEL:
|
|
|
|
return "execution model";
|
|
|
|
case SPV_OPERAND_TYPE_ADDRESSING_MODEL:
|
|
|
|
return "addressing model";
|
|
|
|
case SPV_OPERAND_TYPE_MEMORY_MODEL:
|
|
|
|
return "memory model";
|
|
|
|
case SPV_OPERAND_TYPE_EXECUTION_MODE:
|
|
|
|
return "execution mode";
|
|
|
|
case SPV_OPERAND_TYPE_STORAGE_CLASS:
|
|
|
|
return "storage class";
|
|
|
|
case SPV_OPERAND_TYPE_DIMENSIONALITY:
|
|
|
|
return "dimensionality";
|
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_ADDRESSING_MODE:
|
2015-11-24 23:37:24 +00:00
|
|
|
return "sampler addressing mode";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_FILTER_MODE:
|
|
|
|
return "sampler filter mode";
|
2015-09-16 19:56:43 +00:00
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_IMAGE_FORMAT:
|
2015-10-13 16:54:47 +00:00
|
|
|
return "image format";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_FP_FAST_MATH_MODE:
|
2015-10-13 19:02:03 +00:00
|
|
|
return "floating-point fast math mode";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_FP_ROUNDING_MODE:
|
2015-10-13 19:02:03 +00:00
|
|
|
return "floating-point rounding mode";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_LINKAGE_TYPE:
|
|
|
|
return "linkage type";
|
|
|
|
case SPV_OPERAND_TYPE_ACCESS_QUALIFIER:
|
2016-02-15 18:50:00 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_ACCESS_QUALIFIER:
|
2015-05-22 17:26:19 +00:00
|
|
|
return "access qualifier";
|
|
|
|
case SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE:
|
|
|
|
return "function parameter attribute";
|
|
|
|
case SPV_OPERAND_TYPE_DECORATION:
|
|
|
|
return "decoration";
|
|
|
|
case SPV_OPERAND_TYPE_BUILT_IN:
|
2015-10-13 19:39:38 +00:00
|
|
|
return "built-in";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_SELECTION_CONTROL:
|
|
|
|
return "selection control";
|
|
|
|
case SPV_OPERAND_TYPE_LOOP_CONTROL:
|
|
|
|
return "loop control";
|
|
|
|
case SPV_OPERAND_TYPE_FUNCTION_CONTROL:
|
|
|
|
return "function control";
|
2015-11-18 20:48:32 +00:00
|
|
|
case SPV_OPERAND_TYPE_MEMORY_SEMANTICS_ID:
|
2015-11-24 23:37:24 +00:00
|
|
|
return "memory semantics ID";
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_MEMORY_ACCESS:
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS:
|
2015-05-22 17:26:19 +00:00
|
|
|
return "memory access";
|
2015-11-18 20:48:32 +00:00
|
|
|
case SPV_OPERAND_TYPE_SCOPE_ID:
|
2015-11-24 23:37:24 +00:00
|
|
|
return "scope ID";
|
2015-05-22 17:26:19 +00:00
|
|
|
case SPV_OPERAND_TYPE_GROUP_OPERATION:
|
|
|
|
return "group operation";
|
|
|
|
case SPV_OPERAND_TYPE_KERNEL_ENQ_FLAGS:
|
|
|
|
return "kernel enqeue flags";
|
2015-08-27 17:11:01 +00:00
|
|
|
case SPV_OPERAND_TYPE_KERNEL_PROFILING_INFO:
|
2015-05-22 17:26:19 +00:00
|
|
|
return "kernel profiling info";
|
|
|
|
case SPV_OPERAND_TYPE_CAPABILITY:
|
|
|
|
return "capability";
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_IMAGE:
|
2015-09-18 15:19:18 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_IMAGE:
|
2015-11-24 23:37:24 +00:00
|
|
|
return "image";
|
2015-11-04 22:38:17 +00:00
|
|
|
case SPV_OPERAND_TYPE_OPTIONAL_CIV:
|
|
|
|
return "context-insensitive value";
|
2017-12-03 17:30:08 +00:00
|
|
|
case SPV_OPERAND_TYPE_DEBUG_INFO_FLAGS:
|
|
|
|
return "debug info flags";
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_BASE_TYPE_ATTRIBUTE_ENCODING:
|
|
|
|
return "debug base type encoding";
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_COMPOSITE_TYPE:
|
|
|
|
return "debug composite type";
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_TYPE_QUALIFIER:
|
|
|
|
return "debug type qualifier";
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_OPERATION:
|
|
|
|
return "debug operation";
|
2015-11-04 22:38:17 +00:00
|
|
|
|
|
|
|
// The next values are for values returned from an instruction, not actually
|
|
|
|
// an operand. So the specific strings don't matter. But let's add them
|
|
|
|
// for completeness and ease of testing.
|
|
|
|
case SPV_OPERAND_TYPE_IMAGE_CHANNEL_ORDER:
|
|
|
|
return "image channel order";
|
|
|
|
case SPV_OPERAND_TYPE_IMAGE_CHANNEL_DATA_TYPE:
|
|
|
|
return "image channel data type";
|
|
|
|
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
case SPV_OPERAND_TYPE_NONE:
|
|
|
|
return "NONE";
|
2015-05-22 17:26:19 +00:00
|
|
|
default:
|
|
|
|
assert(0 && "Unhandled operand type!");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return "unknown";
|
|
|
|
}
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
|
2017-06-27 23:28:22 +00:00
|
|
|
void spvPushOperandTypes(const spv_operand_type_t* types,
|
|
|
|
spv_operand_pattern_t* pattern) {
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
const spv_operand_type_t* endTypes;
|
2015-09-29 14:56:32 +00:00
|
|
|
for (endTypes = types; *endTypes != SPV_OPERAND_TYPE_NONE; ++endTypes)
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
;
|
2017-06-27 23:28:22 +00:00
|
|
|
while (endTypes-- != types) {
|
2017-09-21 21:24:57 +00:00
|
|
|
pattern->push_back(*endTypes);
|
2017-06-27 23:28:22 +00:00
|
|
|
}
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
}
|
|
|
|
|
2018-03-14 17:06:18 +00:00
|
|
|
void spvPushOperandTypesForMask(spv_target_env env,
|
|
|
|
const spv_operand_table operandTable,
|
2017-06-27 23:28:22 +00:00
|
|
|
const spv_operand_type_t type,
|
|
|
|
const uint32_t mask,
|
|
|
|
spv_operand_pattern_t* pattern) {
|
|
|
|
// Scan from highest bits to lowest bits because we will append in LIFO
|
|
|
|
// fashion, and we need the operands for lower order bits to be consumed first
|
2017-09-21 21:24:57 +00:00
|
|
|
for (uint32_t candidate_bit = (1u << 31u); candidate_bit;
|
|
|
|
candidate_bit >>= 1) {
|
2015-09-17 21:06:10 +00:00
|
|
|
if (candidate_bit & mask) {
|
|
|
|
spv_operand_desc entry = nullptr;
|
2018-03-14 17:06:18 +00:00
|
|
|
if (SPV_SUCCESS == spvOperandTableValueLookup(env, operandTable, type,
|
2015-09-17 21:06:10 +00:00
|
|
|
candidate_bit, &entry)) {
|
2017-06-27 23:28:22 +00:00
|
|
|
spvPushOperandTypes(entry->operandTypes, pattern);
|
2015-09-17 21:06:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-03 19:26:16 +00:00
|
|
|
bool spvOperandIsConcrete(spv_operand_type_t type) {
|
|
|
|
if (spvIsIdType(type) || spvOperandIsConcreteMask(type)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
switch (type) {
|
|
|
|
case SPV_OPERAND_TYPE_LITERAL_INTEGER:
|
|
|
|
case SPV_OPERAND_TYPE_EXTENSION_INSTRUCTION_NUMBER:
|
|
|
|
case SPV_OPERAND_TYPE_SPEC_CONSTANT_OP_NUMBER:
|
|
|
|
case SPV_OPERAND_TYPE_TYPED_LITERAL_NUMBER:
|
|
|
|
case SPV_OPERAND_TYPE_LITERAL_STRING:
|
|
|
|
case SPV_OPERAND_TYPE_SOURCE_LANGUAGE:
|
|
|
|
case SPV_OPERAND_TYPE_EXECUTION_MODEL:
|
|
|
|
case SPV_OPERAND_TYPE_ADDRESSING_MODEL:
|
|
|
|
case SPV_OPERAND_TYPE_MEMORY_MODEL:
|
|
|
|
case SPV_OPERAND_TYPE_EXECUTION_MODE:
|
|
|
|
case SPV_OPERAND_TYPE_STORAGE_CLASS:
|
|
|
|
case SPV_OPERAND_TYPE_DIMENSIONALITY:
|
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_ADDRESSING_MODE:
|
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_FILTER_MODE:
|
|
|
|
case SPV_OPERAND_TYPE_SAMPLER_IMAGE_FORMAT:
|
|
|
|
case SPV_OPERAND_TYPE_IMAGE_CHANNEL_ORDER:
|
|
|
|
case SPV_OPERAND_TYPE_IMAGE_CHANNEL_DATA_TYPE:
|
|
|
|
case SPV_OPERAND_TYPE_FP_ROUNDING_MODE:
|
|
|
|
case SPV_OPERAND_TYPE_LINKAGE_TYPE:
|
|
|
|
case SPV_OPERAND_TYPE_ACCESS_QUALIFIER:
|
|
|
|
case SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE:
|
|
|
|
case SPV_OPERAND_TYPE_DECORATION:
|
|
|
|
case SPV_OPERAND_TYPE_BUILT_IN:
|
|
|
|
case SPV_OPERAND_TYPE_GROUP_OPERATION:
|
|
|
|
case SPV_OPERAND_TYPE_KERNEL_ENQ_FLAGS:
|
|
|
|
case SPV_OPERAND_TYPE_KERNEL_PROFILING_INFO:
|
|
|
|
case SPV_OPERAND_TYPE_CAPABILITY:
|
2017-12-03 17:30:08 +00:00
|
|
|
case SPV_OPERAND_TYPE_DEBUG_BASE_TYPE_ATTRIBUTE_ENCODING:
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_COMPOSITE_TYPE:
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_TYPE_QUALIFIER:
|
|
|
|
case SPV_OPERAND_TYPE_DEBUG_OPERATION:
|
2017-12-03 19:26:16 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-02 17:05:34 +00:00
|
|
|
bool spvOperandIsConcreteMask(spv_operand_type_t type) {
|
2017-12-03 19:26:16 +00:00
|
|
|
switch (type) {
|
|
|
|
case SPV_OPERAND_TYPE_IMAGE:
|
|
|
|
case SPV_OPERAND_TYPE_FP_FAST_MATH_MODE:
|
|
|
|
case SPV_OPERAND_TYPE_SELECTION_CONTROL:
|
|
|
|
case SPV_OPERAND_TYPE_LOOP_CONTROL:
|
|
|
|
case SPV_OPERAND_TYPE_FUNCTION_CONTROL:
|
|
|
|
case SPV_OPERAND_TYPE_MEMORY_ACCESS:
|
2017-12-03 17:30:08 +00:00
|
|
|
case SPV_OPERAND_TYPE_DEBUG_INFO_FLAGS:
|
2017-12-03 19:26:16 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
2016-02-02 17:05:34 +00:00
|
|
|
}
|
|
|
|
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
bool spvOperandIsOptional(spv_operand_type_t type) {
|
2015-11-04 22:38:17 +00:00
|
|
|
return SPV_OPERAND_TYPE_FIRST_OPTIONAL_TYPE <= type &&
|
|
|
|
type <= SPV_OPERAND_TYPE_LAST_OPTIONAL_TYPE;
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool spvOperandIsVariable(spv_operand_type_t type) {
|
2015-11-04 22:38:17 +00:00
|
|
|
return SPV_OPERAND_TYPE_FIRST_VARIABLE_TYPE <= type &&
|
|
|
|
type <= SPV_OPERAND_TYPE_LAST_VARIABLE_TYPE;
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool spvExpandOperandSequenceOnce(spv_operand_type_t type,
|
|
|
|
spv_operand_pattern_t* pattern) {
|
|
|
|
switch (type) {
|
|
|
|
case SPV_OPERAND_TYPE_VARIABLE_ID:
|
2017-06-27 23:28:22 +00:00
|
|
|
pattern->push_back(type);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_OPTIONAL_ID);
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
return true;
|
2015-10-14 21:02:39 +00:00
|
|
|
case SPV_OPERAND_TYPE_VARIABLE_LITERAL_INTEGER:
|
2017-06-27 23:28:22 +00:00
|
|
|
pattern->push_back(type);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_OPTIONAL_LITERAL_INTEGER);
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
return true;
|
2015-10-14 21:02:39 +00:00
|
|
|
case SPV_OPERAND_TYPE_VARIABLE_LITERAL_INTEGER_ID:
|
2015-11-04 22:38:17 +00:00
|
|
|
// Represents Zero or more (Literal number, Id) pairs,
|
|
|
|
// where the literal number must be a scalar integer.
|
2017-06-27 23:28:22 +00:00
|
|
|
pattern->push_back(type);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_ID);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_OPTIONAL_TYPED_LITERAL_INTEGER);
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
return true;
|
2015-10-14 21:02:39 +00:00
|
|
|
case SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_INTEGER:
|
2015-09-25 18:23:29 +00:00
|
|
|
// Represents Zero or more (Id, Literal number) pairs.
|
2017-06-27 23:28:22 +00:00
|
|
|
pattern->push_back(type);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_LITERAL_INTEGER);
|
|
|
|
pattern->push_back(SPV_OPERAND_TYPE_OPTIONAL_ID);
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-09-29 14:56:32 +00:00
|
|
|
spv_operand_type_t spvTakeFirstMatchableOperand(
|
|
|
|
spv_operand_pattern_t* pattern) {
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
assert(!pattern->empty());
|
|
|
|
spv_operand_type_t result;
|
|
|
|
do {
|
2017-06-27 23:28:22 +00:00
|
|
|
result = pattern->back();
|
|
|
|
pattern->pop_back();
|
2015-09-29 14:56:32 +00:00
|
|
|
} while (spvExpandOperandSequenceOnce(result, pattern));
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
return result;
|
|
|
|
}
|
2015-09-28 21:04:39 +00:00
|
|
|
|
2015-09-29 14:38:18 +00:00
|
|
|
spv_operand_pattern_t spvAlternatePatternFollowingImmediate(
|
|
|
|
const spv_operand_pattern_t& pattern) {
|
2017-09-21 21:24:57 +00:00
|
|
|
auto it =
|
|
|
|
std::find(pattern.crbegin(), pattern.crend(), SPV_OPERAND_TYPE_RESULT_ID);
|
2017-06-27 23:28:22 +00:00
|
|
|
if (it != pattern.crend()) {
|
2017-09-21 21:24:57 +00:00
|
|
|
spv_operand_pattern_t alternatePattern(it - pattern.crbegin() + 2,
|
|
|
|
SPV_OPERAND_TYPE_OPTIONAL_CIV);
|
2017-06-27 23:28:22 +00:00
|
|
|
alternatePattern[1] = SPV_OPERAND_TYPE_RESULT_ID;
|
|
|
|
return alternatePattern;
|
2015-09-28 21:04:39 +00:00
|
|
|
}
|
2017-06-27 23:28:22 +00:00
|
|
|
|
2015-09-29 14:38:18 +00:00
|
|
|
// No result-id found, so just expect CIVs.
|
2017-09-21 21:24:57 +00:00
|
|
|
return {SPV_OPERAND_TYPE_OPTIONAL_CIV};
|
2015-09-28 21:04:39 +00:00
|
|
|
}
|
2016-01-15 16:25:11 +00:00
|
|
|
|
|
|
|
bool spvIsIdType(spv_operand_type_t type) {
|
|
|
|
switch (type) {
|
|
|
|
case SPV_OPERAND_TYPE_ID:
|
|
|
|
case SPV_OPERAND_TYPE_TYPE_ID:
|
|
|
|
case SPV_OPERAND_TYPE_RESULT_ID:
|
|
|
|
case SPV_OPERAND_TYPE_MEMORY_SEMANTICS_ID:
|
|
|
|
case SPV_OPERAND_TYPE_SCOPE_ID:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2017-08-09 18:01:12 +00:00
|
|
|
|
|
|
|
std::function<bool(unsigned)> spvOperandCanBeForwardDeclaredFunction(
|
|
|
|
SpvOp opcode) {
|
|
|
|
std::function<bool(unsigned index)> out;
|
|
|
|
switch (opcode) {
|
|
|
|
case SpvOpExecutionMode:
|
|
|
|
case SpvOpEntryPoint:
|
|
|
|
case SpvOpName:
|
|
|
|
case SpvOpMemberName:
|
|
|
|
case SpvOpSelectionMerge:
|
|
|
|
case SpvOpDecorate:
|
|
|
|
case SpvOpMemberDecorate:
|
2018-03-05 18:34:13 +00:00
|
|
|
case SpvOpDecorateId:
|
|
|
|
case SpvOpDecorateStringGOOGLE:
|
|
|
|
case SpvOpMemberDecorateStringGOOGLE:
|
2017-08-09 18:01:12 +00:00
|
|
|
case SpvOpTypeStruct:
|
|
|
|
case SpvOpBranch:
|
|
|
|
case SpvOpLoopMerge:
|
|
|
|
out = [](unsigned) { return true; };
|
|
|
|
break;
|
|
|
|
case SpvOpGroupDecorate:
|
|
|
|
case SpvOpGroupMemberDecorate:
|
|
|
|
case SpvOpBranchConditional:
|
|
|
|
case SpvOpSwitch:
|
|
|
|
out = [](unsigned index) { return index != 0; };
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SpvOpFunctionCall:
|
|
|
|
// The Function parameter.
|
|
|
|
out = [](unsigned index) { return index == 2; };
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SpvOpPhi:
|
|
|
|
out = [](unsigned index) { return index > 1; };
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SpvOpEnqueueKernel:
|
|
|
|
// The Invoke parameter.
|
|
|
|
out = [](unsigned index) { return index == 8; };
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SpvOpGetKernelNDrangeSubGroupCount:
|
|
|
|
case SpvOpGetKernelNDrangeMaxSubGroupSize:
|
|
|
|
// The Invoke parameter.
|
|
|
|
out = [](unsigned index) { return index == 3; };
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SpvOpGetKernelWorkGroupSize:
|
|
|
|
case SpvOpGetKernelPreferredWorkGroupSizeMultiple:
|
|
|
|
// The Invoke parameter.
|
|
|
|
out = [](unsigned index) { return index == 2; };
|
|
|
|
break;
|
|
|
|
case SpvOpTypeForwardPointer:
|
|
|
|
out = [](unsigned index) { return index == 0; };
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
out = [](unsigned) { return false; };
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return out;
|
|
|
|
}
|