AuroraMiddleware/SPIRV-Tools
1
0
Fork 0
mirror of https://github.com/KhronosGroup/SPIRV-Tools synced 2024-11-30 06:50:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
c25b5bea35
SPIRV-Tools/test/operand_pattern_test.cpp

268 lines
11 KiB
C++
Raw Normal View History

Extend copyright to 2016.
2016-01-07 18:44:22 +00:00
// Copyright (c) 2015-2016 The Khronos Group Inc.
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
//
Relicense SPIRV-Tools under Apache 2.0 Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/383 Finalize v2016.4
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
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
//
Relicense SPIRV-Tools under Apache 2.0 Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/383 Finalize v2016.4
2016-09-01 19:33:59 +00:00
// http://www.apache.org/licenses/LICENSE-2.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
//
Relicense SPIRV-Tools under Apache 2.0 Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/383 Finalize v2016.4
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.
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
Renaming test files to comply with Google style guide. Also posfixing test files with `_test' to make it more clear.
2016-09-22 15:05:30 +00:00
#include "unit_spirv.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
#include "gmock/gmock.h"
Avoid relative path in #include Adds CMAKE_CURRENT_SOURCE_DIR to the include path for UnitSPIRV
2015-12-22 20:15:46 +00:00
#include "source/operand.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
using ::testing::Eq;
namespace {
TEST(OperandPattern, InitiallyEmpty) {
spv_operand_pattern_t empty;
EXPECT_THAT(empty, Eq(spv_operand_pattern_t{}));
EXPECT_EQ(0u, empty.size());
EXPECT_TRUE(empty.empty());
}
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
TEST(OperandPattern, PushBacksAreOnTheRight) {
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
spv_operand_pattern_t pattern;
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
pattern.push_back(SPV_OPERAND_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
EXPECT_THAT(pattern, Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_ID}));
EXPECT_EQ(1u, pattern.size());
EXPECT_TRUE(!pattern.empty());
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
EXPECT_EQ(SPV_OPERAND_TYPE_ID, pattern.back());
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
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
pattern.push_back(SPV_OPERAND_TYPE_NONE);
EXPECT_THAT(pattern, Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_ID,
SPV_OPERAND_TYPE_NONE}));
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
EXPECT_EQ(2u, pattern.size());
EXPECT_TRUE(!pattern.empty());
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
EXPECT_EQ(SPV_OPERAND_TYPE_NONE, pattern.back());
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
}
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
TEST(OperandPattern, PopBacksAreOnTheRight) {
spv_operand_pattern_t pattern{SPV_OPERAND_TYPE_ID,
SPV_OPERAND_TYPE_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
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
pattern.pop_back();
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
EXPECT_THAT(pattern, Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_ID}));
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
pattern.pop_back();
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
EXPECT_THAT(pattern, Eq(spv_operand_pattern_t{}));
}
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
// A test case for typed mask expansion
struct MaskExpansionCase {
A bunch of small fixes to build in MSVC2013. Fixed an issue where some of the tests were testing the wrong word with the wrong operation. (| != ||). Coalesced the many versions of EnumCase into one. Added a get_value() to EnumCase to convert to a uint32_t. Replaces ASSERT_TRUE(pointer), with ASSERT_NE(nullptr, pointer), so that we do not do implicit pointer->bool conversion. Removed const from some test structs since gtest needs to be able to swap them.
2015-09-18 15:50:54 +00:00
spv_operand_type_t type;
uint32_t mask;
spv_operand_pattern_t initial;
spv_operand_pattern_t expected;
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
};
using MaskExpansionTest = ::testing::TestWithParam<MaskExpansionCase>;
TEST_P(MaskExpansionTest, Sample) {
spv_operand_table operandTable = nullptr;
Add SPIR-V 1.1 grammar. Switch to SPIR-V 1.1 as default. Introduce SPV_ENV_UNIVERSAL_1_1. Add "1_0" to the internal variable names. Add spv_target_env to spv*GetTable().
2016-04-07 18:41:34 +00:00
ASSERT_EQ(SPV_SUCCESS,
spvOperandTableGet(&operandTable, SPV_ENV_UNIVERSAL_1_0));
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
spv_operand_pattern_t pattern(GetParam().initial);
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
spvPushOperandTypesForMask(operandTable, GetParam().type, GetParam().mask,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
&pattern);
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
EXPECT_THAT(pattern, Eq(GetParam().expected));
}
// These macros let us write non-trivial examples without too much text.
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
#define PREFIX0 SPV_OPERAND_TYPE_ID, SPV_OPERAND_TYPE_NONE
#define PREFIX1 \
SPV_OPERAND_TYPE_STORAGE_CLASS, SPV_OPERAND_TYPE_SAMPLER_FILTER_MODE, \
SPV_OPERAND_TYPE_ID
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
INSTANTIATE_TEST_CASE_P(
OperandPattern, MaskExpansionTest,
::testing::ValuesIn(std::vector<MaskExpansionCase>{
// No bits means no change.
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
{SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS, 0, {PREFIX0}, {PREFIX0}},
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
// Unknown bits means no change.
{SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS,
0xfffffffc,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
{PREFIX1},
{PREFIX1}},
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
// Volatile has no operands.
{SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS,
Use spirv.h instead of spirv.hpp. This is a part of the effort to make libspirv.h C-compatible.
2015-10-28 17:40:52 +00:00
SpvMemoryAccessVolatileMask,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
{PREFIX0},
{PREFIX0}},
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
// Aligned has one literal number operand.
{SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS,
Use spirv.h instead of spirv.hpp. This is a part of the effort to make libspirv.h C-compatible.
2015-10-28 17:40:52 +00:00
SpvMemoryAccessAlignedMask,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
{PREFIX1},
{PREFIX1, SPV_OPERAND_TYPE_LITERAL_INTEGER}},
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +00:00
// Volatile with Aligned still has just one literal number operand.
{SPV_OPERAND_TYPE_OPTIONAL_MEMORY_ACCESS,
Use spirv.h instead of spirv.hpp. This is a part of the effort to make libspirv.h C-compatible.
2015-10-28 17:40:52 +00:00
SpvMemoryAccessVolatileMask | SpvMemoryAccessAlignedMask,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
{PREFIX1},
{PREFIX1, SPV_OPERAND_TYPE_LITERAL_INTEGER}},
Add SPIR-V 1.1 grammar. Switch to SPIR-V 1.1 as default. Introduce SPV_ENV_UNIVERSAL_1_1. Add "1_0" to the internal variable names. Add spv_target_env to spv*GetTable().
2016-04-07 18:41:34 +00:00
}), );
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
#undef PREFIX0
#undef PREFIX1
Assembler: mask expressions where 1 bits imply operands Properly support a memory access mask with a combination of bits, including the Aligned bit. When the Aligned bit is set, the parser should expect an alignment value literal operand.
2015-09-17 21:06:10 +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
// Returns a vector of all operand types that can be used in a pattern.
std::vector<spv_operand_type_t> allOperandTypes() {
std::vector<spv_operand_type_t> result;
for (int i = 0; i < SPV_OPERAND_TYPE_NUM_OPERAND_TYPES; i++) {
result.push_back(spv_operand_type_t(i));
}
return result;
}
using MatchableOperandExpansionTest =
::testing::TestWithParam<spv_operand_type_t>;
TEST_P(MatchableOperandExpansionTest, MatchableOperandsDontExpand) {
const spv_operand_type_t type = GetParam();
if (!spvOperandIsVariable(type)) {
spv_operand_pattern_t pattern;
const bool did_expand = spvExpandOperandSequenceOnce(type, &pattern);
Clean up CMake configuration and address compiler warnings. - Removed dead configuration in CMakeLists.txt. - Used target_compile_options() instead of CMAKE_{C|CXX}_FLAGS. - Turned on warnings on tests. - Fixed various warnings for comparing signed with unsigned values. - Removed dead code exposed by compiler warnings.
2015-11-18 14:22:10 +00:00
EXPECT_FALSE(did_expand);
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
EXPECT_THAT(pattern, Eq(spv_operand_pattern_t{}));
}
}
INSTANTIATE_TEST_CASE_P(MatchableOperandExpansion,
MatchableOperandExpansionTest,
Add SPIR-V 1.1 grammar. Switch to SPIR-V 1.1 as default. Introduce SPV_ENV_UNIVERSAL_1_1. Add "1_0" to the internal variable names. Add spv_target_env to spv*GetTable().
2016-04-07 18:41:34 +00:00
::testing::ValuesIn(allOperandTypes()), );
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
using VariableOperandExpansionTest =
::testing::TestWithParam<spv_operand_type_t>;
TEST_P(VariableOperandExpansionTest, NonMatchableOperandsExpand) {
const spv_operand_type_t type = GetParam();
if (spvOperandIsVariable(type)) {
spv_operand_pattern_t pattern;
const bool did_expand = spvExpandOperandSequenceOnce(type, &pattern);
Clean up CMake configuration and address compiler warnings. - Removed dead configuration in CMakeLists.txt. - Used target_compile_options() instead of CMAKE_{C|CXX}_FLAGS. - Turned on warnings on tests. - Fixed various warnings for comparing signed with unsigned values. - Removed dead code exposed by compiler warnings.
2015-11-18 14:22:10 +00:00
EXPECT_TRUE(did_expand);
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
EXPECT_FALSE(pattern.empty());
// For the existing rules, the first expansion of a zero-or-more operand
// type yields a matchable operand type. This isn't strictly necessary.
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
EXPECT_FALSE(spvOperandIsVariable(pattern.back()));
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
}
}
INSTANTIATE_TEST_CASE_P(NonMatchableOperandExpansion,
VariableOperandExpansionTest,
Add SPIR-V 1.1 grammar. Switch to SPIR-V 1.1 as default. Introduce SPV_ENV_UNIVERSAL_1_1. Add "1_0" to the internal variable names. Add spv_target_env to spv*GetTable().
2016-04-07 18:41:34 +00:00
::testing::ValuesIn(allOperandTypes()), );
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
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
TEST(AlternatePatternFollowingImmediate, Empty) {
EXPECT_THAT(spvAlternatePatternFollowingImmediate({}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
}
TEST(AlternatePatternFollowingImmediate, SingleElement) {
// Spot-check a random selection of types.
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
Enforce suitable literal number operands to be unsigned integers. Except for OpConstant and OpSpecConstant, all other literal number operands are indeed unsigned integers. So, * Rename all *LITERAL_NUMBER* operand types to *LITERAL_INTEGER*. * Expect unsigned integers for *LITERAL_INTEGER* operands. * Keep MULITPLE_WORD_LITERAL untouched since it is only used by OpConstant and OpSpecConstant. And we want to provide the capability to specify floating-point numbers after !<integer> in the alternate parsing mode. So, OPTIONAL_LITERAL_NUMBER is reserved for OPTIONAL_CIV.
2015-10-14 21:02:39 +00:00
{SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_INTEGER}),
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(
spvAlternatePatternFollowingImmediate({SPV_OPERAND_TYPE_CAPABILITY}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(
spvAlternatePatternFollowingImmediate({SPV_OPERAND_TYPE_LOOP_CONTROL}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
Enforce suitable literal number operands to be unsigned integers. Except for OpConstant and OpSpecConstant, all other literal number operands are indeed unsigned integers. So, * Rename all *LITERAL_NUMBER* operand types to *LITERAL_INTEGER*. * Expect unsigned integers for *LITERAL_INTEGER* operands. * Keep MULITPLE_WORD_LITERAL untouched since it is only used by OpConstant and OpSpecConstant. And we want to provide the capability to specify floating-point numbers after !<integer> in the alternate parsing mode. So, OPTIONAL_LITERAL_NUMBER is reserved for OPTIONAL_CIV.
2015-10-14 21:02:39 +00:00
{SPV_OPERAND_TYPE_OPTIONAL_LITERAL_INTEGER}),
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(spvAlternatePatternFollowingImmediate({SPV_OPERAND_TYPE_ID}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
}
TEST(AlternatePatternFollowingImmediate, SingleResultId) {
EXPECT_THAT(
spvAlternatePatternFollowingImmediate({SPV_OPERAND_TYPE_RESULT_ID}),
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_RESULT_ID}));
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
}
TEST(AlternatePatternFollowingImmediate, MultipleNonResultIds) {
EXPECT_THAT(
spvAlternatePatternFollowingImmediate(
Enforce suitable literal number operands to be unsigned integers. Except for OpConstant and OpSpecConstant, all other literal number operands are indeed unsigned integers. So, * Rename all *LITERAL_NUMBER* operand types to *LITERAL_INTEGER*. * Expect unsigned integers for *LITERAL_INTEGER* operands. * Keep MULITPLE_WORD_LITERAL untouched since it is only used by OpConstant and OpSpecConstant. And we want to provide the capability to specify floating-point numbers after !<integer> in the alternate parsing mode. So, OPTIONAL_LITERAL_NUMBER is reserved for OPTIONAL_CIV.
2015-10-14 21:02:39 +00:00
{SPV_OPERAND_TYPE_VARIABLE_ID_LITERAL_INTEGER,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
SPV_OPERAND_TYPE_CAPABILITY, SPV_OPERAND_TYPE_LOOP_CONTROL,
OpExecutionMode only takes a single ExecutionMode Previously, the grammar allowed many execution modes for a single OpExecutionMode instruction. Removes the variable- and optional- execution mode operand type enum values. Issue found by antiagainst@
2016-03-29 18:49:05 +00:00
SPV_OPERAND_TYPE_OPTIONAL_LITERAL_INTEGER, SPV_OPERAND_TYPE_ID}),
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV}));
}
TEST(AlternatePatternFollowingImmediate, ResultIdFront) {
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_RESULT_ID, SPV_OPERAND_TYPE_ID}),
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_RESULT_ID,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_RESULT_ID,
SPV_OPERAND_TYPE_FP_ROUNDING_MODE, SPV_OPERAND_TYPE_ID}),
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_RESULT_ID,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_RESULT_ID, SPV_OPERAND_TYPE_DIMENSIONALITY,
SPV_OPERAND_TYPE_LINKAGE_TYPE,
SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE,
SPV_OPERAND_TYPE_FP_ROUNDING_MODE, SPV_OPERAND_TYPE_ID,
SPV_OPERAND_TYPE_VARIABLE_ID}),
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_RESULT_ID,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_OPTIONAL_CIV,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV}));
}
TEST(AlternatePatternFollowingImmediate, ResultIdMiddle) {
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_FP_ROUNDING_MODE,
SPV_OPERAND_TYPE_RESULT_ID, SPV_OPERAND_TYPE_ID}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
SPV_OPERAND_TYPE_RESULT_ID,
SPV_OPERAND_TYPE_OPTIONAL_CIV}));
EXPECT_THAT(
spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_DIMENSIONALITY, SPV_OPERAND_TYPE_LINKAGE_TYPE,
SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE,
SPV_OPERAND_TYPE_RESULT_ID, SPV_OPERAND_TYPE_FP_ROUNDING_MODE,
SPV_OPERAND_TYPE_ID, SPV_OPERAND_TYPE_VARIABLE_ID}),
Eq(spv_operand_pattern_t{
SPV_OPERAND_TYPE_OPTIONAL_CIV, SPV_OPERAND_TYPE_RESULT_ID,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV, SPV_OPERAND_TYPE_OPTIONAL_CIV,
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV}));
}
TEST(AlternatePatternFollowingImmediate, ResultIdBack) {
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_ID, SPV_OPERAND_TYPE_RESULT_ID}),
Eq(spv_operand_pattern_t{SPV_OPERAND_TYPE_OPTIONAL_CIV,
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
SPV_OPERAND_TYPE_RESULT_ID}));
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
EXPECT_THAT(spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_FP_ROUNDING_MODE, SPV_OPERAND_TYPE_ID,
SPV_OPERAND_TYPE_RESULT_ID}),
Eq(spv_operand_pattern_t{
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV, SPV_OPERAND_TYPE_RESULT_ID}));
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +00:00
EXPECT_THAT(
spvAlternatePatternFollowingImmediate(
{SPV_OPERAND_TYPE_DIMENSIONALITY, SPV_OPERAND_TYPE_LINKAGE_TYPE,
SPV_OPERAND_TYPE_FUNCTION_PARAMETER_ATTRIBUTE,
SPV_OPERAND_TYPE_FP_ROUNDING_MODE, SPV_OPERAND_TYPE_ID,
SPV_OPERAND_TYPE_VARIABLE_ID, SPV_OPERAND_TYPE_RESULT_ID}),
Eq(spv_operand_pattern_t{
Convert pattern stack from deque to vector, and share it Also move various vector::reserve calls to State ctor Negligible perf benefit, but more tidy.
2017-06-27 23:28:22 +00:00
SPV_OPERAND_TYPE_OPTIONAL_CIV, SPV_OPERAND_TYPE_RESULT_ID}));
Simplify (and test) the alternate-parsing pattern.
2015-09-29 14:38:18 +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
} // anonymous namespace
Reference in New Issue Copy Permalink