AuroraMiddleware/SPIRV-Tools
1
0
Fork 0
mirror of https://github.com/KhronosGroup/SPIRV-Tools synced 2024-11-26 21:30:07 +00:00
Code Issues Packages Projects Releases Wiki Activity
52ff534040
SPIRV-Tools/source/opcode.cpp

837 lines
25 KiB
C++
Raw Normal View History

Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
// Copyright (c) 2015 The Khronos Group Inc.
//
// Permission is hereby granted, free of charge, to any person obtaining a
// copy of this software and/or associated documentation files (the
// "Materials"), to deal in the Materials without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Materials, and to
// permit persons to whom the Materials are furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be included
// in all copies or substantial portions of the Materials.
//
// MODIFICATIONS TO THIS FILE MAY MEAN IT NO LONGER ACCURATELY REFLECTS
// KHRONOS STANDARDS. THE UNMODIFIED, NORMATIVE VERSIONS OF KHRONOS
// SPECIFICATIONS AND HEADER INFORMATION ARE LOCATED AT
// https://www.khronos.org/registry/
//
// THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
// IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
// CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
// TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
// MATERIALS OR THE USE OR OTHER DEALINGS IN THE MATERIALS.
#include <libspirv/libspirv.h>
#include "binary.h"
Support strings with up to 65535 chars, and null. 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.
2015-10-06 20:22:00 +00:00
#include "instruction.h"
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
#include "opcode.h"
#include <assert.h>
#include <string.h>
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
namespace {
// Descriptions of each opcode. Each entry describes the format of the
// instruction that follows a particular opcode.
//
// Most fields are initialized statically by including an automatically
// generated file.
// The operandTypes fields are initialized during spvOpcodeInitialize().
//
// TODO(dneto): Some of the macros are quite unreadable. We could make
// good use of constexpr functions, but some compilers don't support that yet.
spv_opcode_desc_t opcodeTableEntries[] = {
#define EmptyList {}
#define List(...) {__VA_ARGS__}
Make capabilities a bitfield in opcode/operand tables.
2015-09-30 20:42:34 +00:00
#define Capability(X) SPV_CAPABILITY_AS_MASK(Capability##X)
#define Capability2(X,Y) Capability(X)|Capability(Y)
#define CapabilityNone 0 // Needed so Capability(None) still expands to valid syntax.
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
#define Instruction(Name,HasResult,HasType,NumLogicalOperands,NumCapabilities,CapabilityRequired,IsVariable,LogicalArgsList) \
{ #Name, \
Op##Name, \
Make capabilities a bitfield in opcode/operand tables.
2015-09-30 20:42:34 +00:00
(NumCapabilities) ? (CapabilityRequired) : 0, \
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
0, {}, /* Filled in later. Operand list, including result id and type id, if needed */ \
HasResult, \
HasType, \
LogicalArgsList },
#include "opcode.inc"
#undef EmptyList
#undef List
#undef Capability
Make capabilities a bitfield in opcode/operand tables.
2015-09-30 20:42:34 +00:00
#undef Capability2
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
#undef CapabilityNone
#undef Instruction
};
// Has the opcodeTableEntries table been fully elaborated?
// That is, are the operandTypes fields initialized?
bool opcodeTableInitialized = false;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
// Opcode API
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
// Converts the given operand class enum (from the SPIR-V document generation
// logic) to the operand type required by the parser.
// This only applies to logical operands.
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
spv_operand_type_t convertOperandClassToType(spv::Op opcode,
spv::OperandClass operandClass) {
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
// The spec document generator uses OptionalOperandLiteral for several kinds
// of repeating values. Our parser needs more specific information about
// what is being repeated.
if (operandClass == OperandOptionalLiteral) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
switch (opcode) {
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::OpLoad:
case spv::OpStore:
case spv::OpCopyMemory:
case spv::OpCopyMemorySized:
Remove SPV_OPERAND_TYPE_VARIABLE_MEMORY_ACCESS 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.
2015-09-17 21:39:45 +00:00
// Expect an optional mask. When the Aligned bit is set in the mask,
// we will later add the expectation of a literal number operand.
return SPV_OPERAND_TYPE_OPTIONAL_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::OpExecutionMode:
return SPV_OPERAND_TYPE_VARIABLE_EXECUTION_MODE;
default:
break;
}
Support multiple word literal numbers as constants. 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.
2015-09-14 19:22:23 +00:00
} else if (operandClass == OperandVariableLiterals) {
if (opcode == spv::OpConstant || opcode == spv::OpSpecConstant)
return SPV_OPERAND_TYPE_MULTIWORD_LITERAL_NUMBER;
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
}
switch(operandClass) {
case OperandNone: return SPV_OPERAND_TYPE_NONE;
case OperandId: return SPV_OPERAND_TYPE_ID;
case OperandOptionalId: return SPV_OPERAND_TYPE_OPTIONAL_ID;
Remove SPV_OPERAND_TYPE_LITERAL 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.
2015-09-25 18:23:29 +00:00
case OperandOptionalImage: return SPV_OPERAND_TYPE_OPTIONAL_IMAGE;
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 OperandVariableIds: return SPV_OPERAND_TYPE_VARIABLE_ID;
Remove SPV_OPERAND_TYPE_LITERAL 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.
2015-09-25 18:23:29 +00:00
// The spec only uses OptionalLiteral for an optional literal number.
case OperandOptionalLiteral: return SPV_OPERAND_TYPE_OPTIONAL_LITERAL_NUMBER;
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 OperandOptionalLiteralString: return SPV_OPERAND_TYPE_OPTIONAL_LITERAL_STRING;
Remove SPV_OPERAND_TYPE_LITERAL 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.
2015-09-25 18:23:29 +00:00
// This is only used for sequences of literal numbers.
case OperandVariableLiterals: return SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER;
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 OperandLiteralNumber: return SPV_OPERAND_TYPE_LITERAL_NUMBER;
case OperandLiteralString: return SPV_OPERAND_TYPE_LITERAL_STRING;
case OperandSource: return SPV_OPERAND_TYPE_SOURCE_LANGUAGE;
case OperandExecutionModel: return SPV_OPERAND_TYPE_EXECUTION_MODEL;
case OperandAddressing: return SPV_OPERAND_TYPE_ADDRESSING_MODEL;
case OperandMemory: return SPV_OPERAND_TYPE_MEMORY_MODEL;
case OperandExecutionMode: return SPV_OPERAND_TYPE_EXECUTION_MODE;
case OperandStorage: return SPV_OPERAND_TYPE_STORAGE_CLASS;
case OperandDimensionality: return SPV_OPERAND_TYPE_DIMENSIONALITY;
case OperandSamplerAddressingMode: return SPV_OPERAND_TYPE_SAMPLER_ADDRESSING_MODE;
case OperandSamplerFilterMode: return SPV_OPERAND_TYPE_SAMPLER_FILTER_MODE;
Assembler test for Dim, ImageFormat enums. Adds SPV_OPERAND_TYPE_SAMPLER_IMAGE_FORMAT, and the translation tables for its values from the spv::ImageFormat values.
2015-09-16 19:56:43 +00:00
case OperandSamplerImageFormat: return SPV_OPERAND_TYPE_SAMPLER_IMAGE_FORMAT;
Document non-use of certain operand types 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.
2015-09-28 19:33:49 +00:00
case OperandImageChannelOrder:
// This is only used to describe the value generated by OpImageQueryOrder.
// It is not used as an operand.
break;
case OperandImageChannelDataType:
// This is only used to describe the value generated by OpImageQueryFormat.
// It is not used as an operand.
break;
case OperandImageOperands:
// This is not used. It's only an artifact of spec generation.
break;
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 OperandFPFastMath: return SPV_OPERAND_TYPE_FP_FAST_MATH_MODE;
case OperandFPRoundingMode: return SPV_OPERAND_TYPE_FP_ROUNDING_MODE;
case OperandLinkageType: return SPV_OPERAND_TYPE_LINKAGE_TYPE;
case OperandAccessQualifier: return SPV_OPERAND_TYPE_ACCESS_QUALIFIER;
case OperandFuncParamAttr: return SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE;
case OperandDecoration: return SPV_OPERAND_TYPE_DECORATION;
case OperandBuiltIn: return SPV_OPERAND_TYPE_BUILT_IN;
case OperandSelect: return SPV_OPERAND_TYPE_SELECTION_CONTROL;
case OperandLoop: return SPV_OPERAND_TYPE_LOOP_CONTROL;
case OperandFunction: return SPV_OPERAND_TYPE_FUNCTION_CONTROL;
case OperandMemorySemantics: return SPV_OPERAND_TYPE_MEMORY_SEMANTICS;
case OperandMemoryAccess:
Document non-use of certain operand types 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.
2015-09-28 19:33:49 +00:00
// This case does not occur in the table for SPIR-V 0.99 Rev 32.
Remove SPV_OPERAND_TYPE_VARIABLE_MEMORY_ACCESS 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.
2015-09-17 21:39:45 +00:00
// We expect that it will become SPV_OPERAND_TYPE_OPTIONAL_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
// and we can remove the special casing above for memory operation
// instructions.
break;
case OperandScope: return SPV_OPERAND_TYPE_EXECUTION_SCOPE;
case OperandGroupOperation: return SPV_OPERAND_TYPE_GROUP_OPERATION;
case OperandKernelEnqueueFlags: return SPV_OPERAND_TYPE_KERNEL_ENQ_FLAGS;
case OperandKernelProfilingInfo: return SPV_OPERAND_TYPE_KERNEL_PROFILING_INFO;
case OperandCapability: return SPV_OPERAND_TYPE_CAPABILITY;
// Used by GroupMemberDecorate
Remove SPV_OPERAND_TYPE_LITERAL 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.
2015-09-25 18:23:29 +00:00
case OperandVariableIdLiteral: return SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_NUMBER;
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
// Used by Switch
Remove SPV_OPERAND_TYPE_LITERAL 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.
2015-09-25 18:23:29 +00:00
case OperandVariableLiteralId: return SPV_OPERAND_TYPE_VARIABLE_LITERAL_NUMBER_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
// These exceptional cases shouldn't occur.
case OperandCount:
default:
break;
}
assert(0 && "Unexpected operand class");
return SPV_OPERAND_TYPE_NONE;
}
Run clang-format.
2015-09-14 14:05:37 +00:00
} // anonymous namespace
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
// Finish populating the opcodeTableEntries array.
void spvOpcodeTableInitialize() {
// Compute the operandTypes field for each entry.
Run clang-format.
2015-09-14 14:05:37 +00:00
for (auto &opcode : opcodeTableEntries) {
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
opcode.numTypes = 0;
// Type ID always comes first, if present.
if (opcode.hasType)
Added tracking to types and validated certain instructions. 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.
2015-09-29 15:28:34 +00:00
opcode.operandTypes[opcode.numTypes++] = SPV_OPERAND_TYPE_TYPE_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
// Result ID always comes next, if present
if (opcode.hasResult)
opcode.operandTypes[opcode.numTypes++] = SPV_OPERAND_TYPE_RESULT_ID;
Run clang-format.
2015-09-14 14:05:37 +00:00
const uint16_t maxNumOperands =
sizeof(opcode.operandTypes) / sizeof(opcode.operandTypes[0]);
const uint16_t maxNumClasses =
sizeof(opcode.operandClass) / sizeof(opcode.operandClass[0]);
for (uint16_t classIndex = 0;
opcode.numTypes < maxNumOperands && classIndex < maxNumClasses;
classIndex++) {
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 OperandClass operandClass = opcode.operandClass[classIndex];
Run clang-format.
2015-09-14 14:05:37 +00:00
opcode.operandTypes[opcode.numTypes++] =
convertOperandClassToType(opcode.opcode, operandClass);
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
// The OperandNone value is not explicitly represented in the .inc file.
// However, it is the zero value, and is created via implicit value
// initialization.
if (operandClass == OperandNone) {
opcode.numTypes--;
break;
}
}
// We should have written the terminating SPV_OPERAND_TYPE_NONE entry, but
// also without overflowing.
Run clang-format.
2015-09-14 14:05:37 +00:00
assert((opcode.numTypes < maxNumOperands) &&
"Operand class list is too long. Expand "
"spv_opcode_desc_t.operandClass");
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
}
opcodeTableInitialized = true;
}
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
const char *spvGeneratorStr(uint32_t generator) {
switch (generator) {
case SPV_GENERATOR_KHRONOS:
return "Khronos";
case SPV_GENERATOR_VALVE:
return "Valve";
case SPV_GENERATOR_LUNARG:
return "LunarG";
case SPV_GENERATOR_CODEPLAY:
return "Codeplay Software Ltd.";
default:
return "Unknown";
}
}
uint32_t spvOpcodeMake(uint16_t wordCount, Op opcode) {
return ((uint32_t)opcode) | (((uint32_t)wordCount) << 16);
}
void spvOpcodeSplit(const uint32_t word, uint16_t *pWordCount, Op *pOpcode) {
if (pWordCount) {
*pWordCount = (uint16_t)((0xffff0000 & word) >> 16);
}
if (pOpcode) {
*pOpcode = (Op)(0x0000ffff & word);
}
}
spv_result_t spvOpcodeTableGet(spv_opcode_table *pInstTable) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (!pInstTable) return SPV_ERROR_INVALID_POINTER;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +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
static spv_opcode_table_t table = {
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
sizeof(opcodeTableEntries) / sizeof(spv_opcode_desc_t),
opcodeTableEntries};
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
// TODO(dneto): Consider thread safety of initialization.
// That is, ordering effects of the flag vs. the table updates.
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (!opcodeTableInitialized) spvOpcodeTableInitialize();
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
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
*pInstTable = &table;
return SPV_SUCCESS;
}
spv_result_t spvOpcodeTableNameLookup(const spv_opcode_table table,
const char *name,
spv_opcode_desc *pEntry) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (!name || !pEntry) return SPV_ERROR_INVALID_POINTER;
if (!table) return SPV_ERROR_INVALID_TABLE;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
// TODO: This lookup of the Opcode table is suboptimal! Binary sort would be
// preferable but the table requires sorting on the Opcode name, but it's
// static
// const initialized and matches the order of the spec.
const size_t nameLength = strlen(name);
for (uint64_t opcodeIndex = 0; opcodeIndex < table->count; ++opcodeIndex) {
if (nameLength == strlen(table->entries[opcodeIndex].name) &&
!strncmp(name, table->entries[opcodeIndex].name, nameLength)) {
// NOTE: Found out Opcode!
*pEntry = &table->entries[opcodeIndex];
return SPV_SUCCESS;
}
}
return SPV_ERROR_INVALID_LOOKUP;
}
spv_result_t spvOpcodeTableValueLookup(const spv_opcode_table table,
const Op opcode,
spv_opcode_desc *pEntry) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (!table) return SPV_ERROR_INVALID_TABLE;
if (!pEntry) return SPV_ERROR_INVALID_POINTER;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
// TODO: As above this lookup is not optimal.
for (uint64_t opcodeIndex = 0; opcodeIndex < table->count; ++opcodeIndex) {
if (opcode == table->entries[opcodeIndex].opcode) {
// NOTE: Found the Opcode!
*pEntry = &table->entries[opcodeIndex];
return SPV_SUCCESS;
}
}
return SPV_ERROR_INVALID_LOOKUP;
}
Support "<result-id> = <opcode> <operand>.." format.
2015-08-21 15:50:55 +00:00
int16_t spvOpcodeResultIdIndex(spv_opcode_desc entry) {
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
for (int16_t i = 0; i < entry->numTypes; ++i) {
Support "<result-id> = <opcode> <operand>.." format.
2015-08-21 15:50:55 +00:00
if (SPV_OPERAND_TYPE_RESULT_ID == entry->operandTypes[i]) return i;
}
return SPV_OPERAND_INVALID_RESULT_ID_INDEX;
}
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
int32_t spvOpcodeRequiresCapabilities(spv_opcode_desc entry) {
Remove spv_opcode_flags_t and flags fields. The flags fields in both spv_opcode_desc_t and spv_operand_desc_t are redundant with the capabilities mask field in the same structure.
2015-10-07 20:58:38 +00:00
return entry->capabilities != 0;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
}
void spvInstructionCopy(const uint32_t *words, const Op opcode,
const uint16_t wordCount, const spv_endianness_t endian,
spv_instruction_t *pInst) {
pInst->opcode = opcode;
Support strings with up to 65535 chars, and null. 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.
2015-10-06 20:22:00 +00:00
pInst->words.resize(wordCount);
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
for (uint16_t wordIndex = 0; wordIndex < wordCount; ++wordIndex) {
pInst->words[wordIndex] = spvFixWord(words[wordIndex], endian);
if (!wordIndex) {
uint16_t thisWordCount;
Op thisOpcode;
spvOpcodeSplit(pInst->words[wordIndex], &thisWordCount, &thisOpcode);
assert(opcode == thisOpcode && wordCount == thisWordCount &&
"Endianness failed!");
}
}
}
const char *spvOpcodeString(const Op opcode) {
#define CASE(OPCODE) \
case OPCODE: \
return #OPCODE;
switch (opcode) {
CASE(OpNop)
CASE(OpSource)
CASE(OpSourceExtension)
CASE(OpExtension)
CASE(OpExtInstImport)
CASE(OpMemoryModel)
CASE(OpEntryPoint)
CASE(OpExecutionMode)
CASE(OpTypeVoid)
CASE(OpTypeBool)
CASE(OpTypeInt)
CASE(OpTypeFloat)
CASE(OpTypeVector)
CASE(OpTypeMatrix)
CASE(OpTypeSampler)
CASE(OpTypeArray)
CASE(OpTypeRuntimeArray)
CASE(OpTypeStruct)
CASE(OpTypeOpaque)
CASE(OpTypePointer)
CASE(OpTypeFunction)
CASE(OpTypeEvent)
CASE(OpTypeDeviceEvent)
CASE(OpTypeReserveId)
CASE(OpTypeQueue)
CASE(OpTypePipe)
CASE(OpConstantTrue)
CASE(OpConstantFalse)
CASE(OpConstant)
CASE(OpConstantComposite)
CASE(OpConstantSampler)
CASE(OpConstantNull)
CASE(OpSpecConstantTrue)
CASE(OpSpecConstantFalse)
CASE(OpSpecConstant)
CASE(OpSpecConstantComposite)
CASE(OpVariable)
CASE(OpFunction)
CASE(OpFunctionParameter)
CASE(OpFunctionEnd)
CASE(OpFunctionCall)
CASE(OpExtInst)
CASE(OpUndef)
CASE(OpLoad)
CASE(OpStore)
CASE(OpPhi)
CASE(OpDecorationGroup)
CASE(OpDecorate)
CASE(OpMemberDecorate)
CASE(OpGroupDecorate)
CASE(OpGroupMemberDecorate)
CASE(OpName)
CASE(OpMemberName)
CASE(OpString)
CASE(OpLine)
CASE(OpVectorExtractDynamic)
CASE(OpVectorInsertDynamic)
CASE(OpVectorShuffle)
CASE(OpCompositeConstruct)
CASE(OpCompositeExtract)
CASE(OpCompositeInsert)
CASE(OpCopyObject)
CASE(OpCopyMemory)
CASE(OpCopyMemorySized)
CASE(OpAccessChain)
CASE(OpInBoundsAccessChain)
CASE(OpSNegate)
CASE(OpFNegate)
CASE(OpNot)
CASE(OpAny)
CASE(OpAll)
CASE(OpConvertFToU)
CASE(OpConvertFToS)
CASE(OpConvertSToF)
CASE(OpConvertUToF)
CASE(OpUConvert)
CASE(OpSConvert)
CASE(OpFConvert)
CASE(OpConvertPtrToU)
CASE(OpConvertUToPtr)
CASE(OpPtrCastToGeneric)
CASE(OpGenericCastToPtr)
CASE(OpBitcast)
CASE(OpTranspose)
CASE(OpIsNan)
CASE(OpIsInf)
CASE(OpIsFinite)
CASE(OpIsNormal)
CASE(OpSignBitSet)
CASE(OpLessOrGreater)
CASE(OpOrdered)
CASE(OpUnordered)
CASE(OpArrayLength)
CASE(OpIAdd)
CASE(OpFAdd)
CASE(OpISub)
CASE(OpFSub)
CASE(OpIMul)
CASE(OpFMul)
CASE(OpUDiv)
CASE(OpSDiv)
CASE(OpFDiv)
CASE(OpUMod)
CASE(OpSRem)
CASE(OpSMod)
CASE(OpFRem)
CASE(OpFMod)
CASE(OpVectorTimesScalar)
CASE(OpMatrixTimesScalar)
CASE(OpVectorTimesMatrix)
CASE(OpMatrixTimesVector)
CASE(OpMatrixTimesMatrix)
CASE(OpOuterProduct)
CASE(OpDot)
CASE(OpShiftRightLogical)
CASE(OpShiftRightArithmetic)
CASE(OpShiftLeftLogical)
CASE(OpLogicalOr)
CASE(OpLogicalAnd)
CASE(OpBitwiseOr)
CASE(OpBitwiseXor)
CASE(OpBitwiseAnd)
CASE(OpSelect)
CASE(OpIEqual)
CASE(OpFOrdEqual)
CASE(OpFUnordEqual)
CASE(OpINotEqual)
CASE(OpFOrdNotEqual)
CASE(OpFUnordNotEqual)
CASE(OpULessThan)
CASE(OpSLessThan)
CASE(OpFOrdLessThan)
CASE(OpFUnordLessThan)
CASE(OpUGreaterThan)
CASE(OpSGreaterThan)
CASE(OpFOrdGreaterThan)
CASE(OpFUnordGreaterThan)
CASE(OpULessThanEqual)
CASE(OpSLessThanEqual)
CASE(OpFOrdLessThanEqual)
CASE(OpFUnordLessThanEqual)
CASE(OpUGreaterThanEqual)
CASE(OpSGreaterThanEqual)
CASE(OpFOrdGreaterThanEqual)
CASE(OpFUnordGreaterThanEqual)
CASE(OpDPdx)
CASE(OpDPdy)
CASE(OpFwidth)
CASE(OpDPdxFine)
CASE(OpDPdyFine)
CASE(OpFwidthFine)
CASE(OpDPdxCoarse)
CASE(OpDPdyCoarse)
CASE(OpFwidthCoarse)
CASE(OpEmitVertex)
CASE(OpEndPrimitive)
CASE(OpEmitStreamVertex)
CASE(OpEndStreamPrimitive)
CASE(OpControlBarrier)
CASE(OpMemoryBarrier)
CASE(OpAtomicLoad)
CASE(OpAtomicStore)
CASE(OpAtomicExchange)
CASE(OpAtomicCompareExchange)
CASE(OpAtomicCompareExchangeWeak)
CASE(OpAtomicIIncrement)
CASE(OpAtomicIDecrement)
CASE(OpAtomicIAdd)
CASE(OpAtomicISub)
CASE(OpAtomicUMin)
CASE(OpAtomicUMax)
CASE(OpAtomicAnd)
CASE(OpAtomicOr)
CASE(OpAtomicXor)
CASE(OpLoopMerge)
CASE(OpSelectionMerge)
CASE(OpLabel)
CASE(OpBranch)
CASE(OpBranchConditional)
CASE(OpSwitch)
CASE(OpKill)
CASE(OpReturn)
CASE(OpReturnValue)
CASE(OpUnreachable)
CASE(OpLifetimeStart)
CASE(OpLifetimeStop)
CASE(OpAsyncGroupCopy)
CASE(OpWaitGroupEvents)
CASE(OpGroupAll)
CASE(OpGroupAny)
CASE(OpGroupBroadcast)
CASE(OpGroupIAdd)
CASE(OpGroupFAdd)
CASE(OpGroupFMin)
CASE(OpGroupUMin)
CASE(OpGroupSMin)
CASE(OpGroupFMax)
CASE(OpGroupUMax)
CASE(OpGroupSMax)
CASE(OpGenericCastToPtrExplicit)
CASE(OpGenericPtrMemSemantics)
CASE(OpReadPipe)
CASE(OpWritePipe)
CASE(OpReservedReadPipe)
CASE(OpReservedWritePipe)
CASE(OpReserveReadPipePackets)
CASE(OpReserveWritePipePackets)
CASE(OpCommitReadPipe)
CASE(OpCommitWritePipe)
CASE(OpIsValidReserveId)
CASE(OpGetNumPipePackets)
CASE(OpGetMaxPipePackets)
CASE(OpGroupReserveReadPipePackets)
CASE(OpGroupReserveWritePipePackets)
CASE(OpGroupCommitReadPipe)
CASE(OpGroupCommitWritePipe)
CASE(OpEnqueueMarker)
CASE(OpEnqueueKernel)
CASE(OpGetKernelNDrangeSubGroupCount)
CASE(OpGetKernelNDrangeMaxSubGroupSize)
CASE(OpGetKernelWorkGroupSize)
CASE(OpGetKernelPreferredWorkGroupSizeMultiple)
CASE(OpRetainEvent)
CASE(OpReleaseEvent)
CASE(OpCreateUserEvent)
CASE(OpIsValidEvent)
CASE(OpSetUserEventStatus)
CASE(OpCaptureEventProfilingInfo)
CASE(OpGetDefaultQueue)
CASE(OpBuildNDRange)
default:
assert(0 && "Unreachable!");
}
#undef CASE
return "unknown";
}
int32_t spvOpcodeIsType(const Op opcode) {
switch (opcode) {
case OpTypeVoid:
case OpTypeBool:
case OpTypeInt:
case OpTypeFloat:
case OpTypeVector:
case OpTypeMatrix:
case OpTypeSampler:
case OpTypeArray:
case OpTypeRuntimeArray:
case OpTypeStruct:
case OpTypeOpaque:
case OpTypePointer:
case OpTypeFunction:
case OpTypeEvent:
case OpTypeDeviceEvent:
case OpTypeReserveId:
case OpTypeQueue:
case OpTypePipe:
return true;
default:
return false;
}
}
int32_t spvOpcodeIsScalarType(const Op opcode) {
switch (opcode) {
case OpTypeInt:
case OpTypeFloat:
return true;
default:
return false;
}
}
int32_t spvOpcodeIsConstant(const Op opcode) {
switch (opcode) {
case OpConstantTrue:
case OpConstantFalse:
case OpConstant:
case OpConstantComposite:
case OpConstantSampler:
// case OpConstantNull:
case OpConstantNull:
case OpSpecConstantTrue:
case OpSpecConstantFalse:
case OpSpecConstant:
case OpSpecConstantComposite:
// case OpSpecConstantOp:
return true;
default:
return false;
}
}
int32_t spvOpcodeIsComposite(const Op opcode) {
switch (opcode) {
case OpTypeVector:
case OpTypeMatrix:
case OpTypeArray:
case OpTypeStruct:
return true;
default:
return false;
}
}
int32_t spvOpcodeAreTypesEqual(const spv_instruction_t *pTypeInst0,
const spv_instruction_t *pTypeInst1) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (pTypeInst0->opcode != pTypeInst1->opcode) return false;
if (pTypeInst0->words[1] != pTypeInst1->words[1]) return false;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
return true;
}
int32_t spvOpcodeIsPointer(const Op opcode) {
switch (opcode) {
case OpVariable:
case OpAccessChain:
case OpInBoundsAccessChain:
case OpFunctionParameter:
return true;
default:
return false;
}
}
int32_t spvOpcodeIsObject(const Op opcode) {
switch (opcode) {
case OpConstantTrue:
case OpConstantFalse:
case OpConstant:
case OpConstantComposite:
// TODO: case OpConstantSampler:
case OpConstantNull:
case OpSpecConstantTrue:
case OpSpecConstantFalse:
case OpSpecConstant:
case OpSpecConstantComposite:
// TODO: case OpSpecConstantOp:
case OpVariable:
case OpAccessChain:
case OpInBoundsAccessChain:
case OpConvertFToU:
case OpConvertFToS:
case OpConvertSToF:
case OpConvertUToF:
case OpUConvert:
case OpSConvert:
case OpFConvert:
case OpConvertPtrToU:
// TODO: case OpConvertUToPtr:
case OpPtrCastToGeneric:
// TODO: case OpGenericCastToPtr:
case OpBitcast:
// TODO: case OpGenericCastToPtrExplicit:
case OpSatConvertSToU:
case OpSatConvertUToS:
case OpVectorExtractDynamic:
case OpCompositeConstruct:
case OpCompositeExtract:
case OpCopyObject:
case OpTranspose:
case OpSNegate:
case OpFNegate:
case OpNot:
case OpIAdd:
case OpFAdd:
case OpISub:
case OpFSub:
case OpIMul:
case OpFMul:
case OpUDiv:
case OpSDiv:
case OpFDiv:
case OpUMod:
case OpSRem:
case OpSMod:
case OpVectorTimesScalar:
case OpMatrixTimesScalar:
case OpVectorTimesMatrix:
case OpMatrixTimesVector:
case OpMatrixTimesMatrix:
case OpOuterProduct:
case OpDot:
case OpShiftRightLogical:
case OpShiftRightArithmetic:
case OpShiftLeftLogical:
case OpBitwiseOr:
case OpBitwiseXor:
case OpBitwiseAnd:
case OpAny:
case OpAll:
case OpIsNan:
case OpIsInf:
case OpIsFinite:
case OpIsNormal:
case OpSignBitSet:
case OpLessOrGreater:
case OpOrdered:
case OpUnordered:
case OpLogicalOr:
case OpLogicalAnd:
case OpSelect:
case OpIEqual:
case OpFOrdEqual:
case OpFUnordEqual:
case OpINotEqual:
case OpFOrdNotEqual:
case OpFUnordNotEqual:
case OpULessThan:
case OpSLessThan:
case OpFOrdLessThan:
case OpFUnordLessThan:
case OpUGreaterThan:
case OpSGreaterThan:
case OpFOrdGreaterThan:
case OpFUnordGreaterThan:
case OpULessThanEqual:
case OpSLessThanEqual:
case OpFOrdLessThanEqual:
case OpFUnordLessThanEqual:
case OpUGreaterThanEqual:
case OpSGreaterThanEqual:
case OpFOrdGreaterThanEqual:
case OpFUnordGreaterThanEqual:
case OpDPdx:
case OpDPdy:
case OpFwidth:
case OpDPdxFine:
case OpDPdyFine:
case OpFwidthFine:
case OpDPdxCoarse:
case OpDPdyCoarse:
case OpFwidthCoarse:
case OpReturnValue:
return true;
default:
return false;
}
}
int32_t spvOpcodeIsBasicTypeNullable(Op opcode) {
switch (opcode) {
case OpTypeBool:
case OpTypeInt:
case OpTypeFloat:
case OpTypePointer:
case OpTypeEvent:
case OpTypeDeviceEvent:
case OpTypeReserveId:
case OpTypeQueue:
return true;
default:
return false;
}
}
int32_t spvInstructionIsInBasicBlock(const spv_instruction_t *pFirstInst,
const spv_instruction_t *pInst) {
while (pFirstInst != pInst) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (OpFunction == pInst->opcode) break;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
pInst--;
}
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (OpFunction != pInst->opcode) return false;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
return true;
}
int32_t spvOpcodeIsValue(Op opcode) {
Limit the use of spvCheck and spvCheckReturn to validator. spvCheck is indeed just an if-statement. Defining such a macro doesn't help much.
2015-09-11 18:31:27 +00:00
if (spvOpcodeIsPointer(opcode)) return true;
if (spvOpcodeIsConstant(opcode)) return true;
Code drop of the Codeplay spirv-tools source. This commit contains the source for the SPIRV static library, spirv-as, spirv-dis, and spirv-val tools.
2015-05-22 17:26:19 +00:00
switch (opcode) {
case OpLoad:
// TODO: Other Opcode's resulting in a value
return true;
default:
return false;
}
}
Added tracking to types and validated certain instructions. 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.
2015-09-29 15:28:34 +00:00
int32_t spvOpcodeGeneratesType(Op op) {
switch(op) {
case OpTypeVoid:
case OpTypeBool:
case OpTypeInt:
case OpTypeFloat:
case OpTypeVector:
case OpTypeMatrix:
case OpTypeImage:
case OpTypeSampler:
case OpTypeSampledImage:
case OpTypeArray:
case OpTypeRuntimeArray:
case OpTypeStruct:
case OpTypeOpaque:
case OpTypePointer:
case OpTypeFunction:
case OpTypeEvent:
case OpTypeDeviceEvent:
case OpTypeReserveId:
case OpTypeQueue:
case OpTypePipe:
case OpTypeForwardPointer:
return true;
default:;
}
return 0;
}
Reference in New Issue Copy Permalink