2016-01-07 18:44:22 +00:00
|
|
|
// Copyright (c) 2015-2016 The Khronos Group Inc.
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
2015-05-22 17:26:19 +00:00
|
|
|
//
|
2016-09-01 19:33:59 +00:00
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2018-08-03 12:05:33 +00:00
|
|
|
#ifndef SOURCE_OPERAND_H_
|
|
|
|
#define SOURCE_OPERAND_H_
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2017-08-09 18:01:12 +00:00
|
|
|
#include <functional>
|
2018-08-03 19:06:09 +00:00
|
|
|
#include <vector>
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
|
2018-08-03 19:06:09 +00:00
|
|
|
#include "source/table.h"
|
2016-02-17 19:44:00 +00:00
|
|
|
#include "spirv-tools/libspirv.h"
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// A sequence of operand types.
|
|
|
|
//
|
|
|
|
// A SPIR-V parser uses an operand pattern to describe what is expected
|
|
|
|
// next on the input.
|
|
|
|
//
|
|
|
|
// As we parse an instruction in text or binary form from left to right,
|
2017-06-27 23:28:22 +00:00
|
|
|
// we pop and push at the end of the pattern vector. Symbols later in the
|
|
|
|
// pattern vector are matched against the input before symbols earlier in the
|
|
|
|
// pattern vector are matched.
|
|
|
|
|
|
|
|
// Using a vector in this way reduces memory traffic, which is good for
|
|
|
|
// performance.
|
|
|
|
using spv_operand_pattern_t = std::vector<spv_operand_type_t>;
|
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
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Finds the named operand in the table. The type parameter specifies the
|
|
|
|
// operand's group. A handle of the operand table entry for this operand will
|
|
|
|
// be written into *entry.
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_result_t spvOperandTableNameLookup(spv_target_env,
|
|
|
|
const spv_operand_table table,
|
2015-05-22 17:26:19 +00:00
|
|
|
const spv_operand_type_t type,
|
2015-09-29 14:56:32 +00:00
|
|
|
const char* name,
|
2015-11-16 15:48:43 +00:00
|
|
|
const size_t name_length,
|
|
|
|
spv_operand_desc* entry);
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Finds the operand with value in the table. The type parameter specifies the
|
|
|
|
// operand's group. A handle of the operand table entry for this operand will
|
|
|
|
// be written into *entry.
|
2018-03-14 17:06:18 +00:00
|
|
|
spv_result_t spvOperandTableValueLookup(spv_target_env,
|
|
|
|
const spv_operand_table table,
|
2015-05-22 17:26:19 +00:00
|
|
|
const spv_operand_type_t type,
|
|
|
|
const uint32_t value,
|
2015-11-16 15:48:43 +00:00
|
|
|
spv_operand_desc* entry);
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Gets the name string of the non-variable operand type.
|
2015-09-29 14:56:32 +00:00
|
|
|
const char* spvOperandTypeStr(spv_operand_type_t type);
|
2015-05-22 17:26:19 +00:00
|
|
|
|
2017-12-03 19:26:16 +00:00
|
|
|
// Returns true if the given type is concrete.
|
|
|
|
bool spvOperandIsConcrete(spv_operand_type_t type);
|
|
|
|
|
|
|
|
// Returns true if the given type is concrete and also a mask.
|
2016-02-02 17:05:34 +00:00
|
|
|
bool spvOperandIsConcreteMask(spv_operand_type_t type);
|
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Returns true if an operand of the given type is optional.
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
bool spvOperandIsOptional(spv_operand_type_t type);
|
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Returns true if an operand type represents zero or more logical operands.
|
|
|
|
//
|
|
|
|
// Note that a single logical operand may still be a variable number of words.
|
|
|
|
// For example, a literal string may be many words, but is just one logical
|
|
|
|
// operand.
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
bool spvOperandIsVariable(spv_operand_type_t type);
|
|
|
|
|
2017-06-27 23:28:22 +00:00
|
|
|
// Append a list of operand types to the end of the pattern vector.
|
2015-11-16 15:48:43 +00:00
|
|
|
// The types parameter specifies the source array of types, ending with
|
|
|
|
// SPV_OPERAND_TYPE_NONE.
|
2017-06-27 23:28:22 +00:00
|
|
|
void spvPushOperandTypes(const spv_operand_type_t* types,
|
|
|
|
spv_operand_pattern_t* pattern);
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
|
2017-06-27 23:28:22 +00:00
|
|
|
// Appends the operands expected after the given typed mask onto the
|
|
|
|
// end of the given pattern.
|
2015-11-16 15:48:43 +00:00
|
|
|
//
|
|
|
|
// Each set bit in the mask represents zero or more operand types that should
|
2017-06-27 23:28:22 +00:00
|
|
|
// be appended onto the pattern. Operands for a less significant bit always
|
|
|
|
// appear after operands for a more significant bit.
|
2015-11-16 15:48:43 +00:00
|
|
|
//
|
|
|
|
// If a set bit is unknown, then we assume it has no operands.
|
2018-03-14 17:06:18 +00:00
|
|
|
void spvPushOperandTypesForMask(spv_target_env,
|
|
|
|
const spv_operand_table operand_table,
|
2017-06-27 23:28:22 +00:00
|
|
|
const spv_operand_type_t mask_type,
|
|
|
|
const uint32_t mask,
|
|
|
|
spv_operand_pattern_t* pattern);
|
2015-09-17 21:06:10 +00:00
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Expands an operand type representing zero or more logical operands,
|
|
|
|
// exactly once.
|
|
|
|
//
|
|
|
|
// If the given type represents potentially several logical operands,
|
|
|
|
// then prepend the given pattern with the first expansion of the logical
|
|
|
|
// operands, followed by original type. Otherwise, don't modify the pattern.
|
|
|
|
//
|
|
|
|
// For example, the SPV_OPERAND_TYPE_VARIABLE_ID represents zero or more
|
|
|
|
// IDs. In that case we would prepend the pattern with SPV_OPERAND_TYPE_ID
|
|
|
|
// followed by SPV_OPERAND_TYPE_VARIABLE_ID again.
|
|
|
|
//
|
|
|
|
// This also applies to zero or more tuples of logical operands. In that case
|
|
|
|
// we prepend pattern with for the members of the tuple, followed by the
|
|
|
|
// original type argument. The pattern must encode the fact that if any part
|
|
|
|
// of the tuple is present, then all tuple members should be. So the first
|
|
|
|
// member of the tuple must be optional, and the remaining members
|
|
|
|
// non-optional.
|
|
|
|
//
|
|
|
|
// Returns true if we modified the pattern.
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
bool spvExpandOperandSequenceOnce(spv_operand_type_t type,
|
|
|
|
spv_operand_pattern_t* pattern);
|
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Expands the first element in the pattern until it is a matchable operand
|
|
|
|
// type, then pops it off the front and returns it. The pattern must not be
|
|
|
|
// empty.
|
|
|
|
//
|
|
|
|
// A matchable operand type is anything other than a zero-or-more-items
|
|
|
|
// operand type.
|
Use opcode operand definitions from SPIR-V specification generator.
The assembler and disassembler now use a dynamically adjusted
sequence of expected operand types. (Internally, it is a deque,
for readability.) Both parsers repeatedly pull an expected operand
type from the left of this pattern list, and try to match the next
input token against it.
The expected pattern is adjusted during the parse to accommodate:
- an extended instruction's expected operands, depending on the
extended instruction's index.
- when an operand itself has operands
- to handle sequences of zero or more operands, or pairs of
operands. These are expanded lazily during the parse.
Adds spv::OperandClass from the SPIR-V specification generator.
Modifies spv_operand_desc_t:
- adds hasResult, hasType, and operandClass array to the opcode
description type.
- "wordCount" is replaced with "numTypes", which counts the number
of entries in operandTypes. And each of those describes a
*logical* operand, including the type id for the instruction,
and the result id for the instruction. A logical operand could be
variable-width, such as a literal string.
Adds opcode.inc, an automatically-generated table of operation
descriptions, with one line to describe each core instruction.
Externally, we have modified the SPIR-V spec doc generator to
emit this file.
(We have hacked this copy to use the old semantics for OpLine.)
Inside the assembler, parsing an operand may fail with new
error code SPV_FAIL_MATCH. For an optional operand, this is not
fatal, but should trigger backtracking at a higher level.
The spvTextIsStartOfNewInst checks the case of the third letter
of what might be an opcode. So now, "OpenCL" does not look like
an opcode name.
In assembly, the EntryPoint name field is mandatory, but can be
an empty string.
Adjust tests for changes to:
- OpSampedImage
- OpTypeSampler
2015-08-27 17:03:52 +00:00
|
|
|
spv_operand_type_t spvTakeFirstMatchableOperand(spv_operand_pattern_t* pattern);
|
|
|
|
|
2015-11-16 15:48:43 +00:00
|
|
|
// Calculates the corresponding post-immediate alternate pattern, which allows
|
|
|
|
// a limited set of operand types.
|
2015-09-29 14:38:18 +00:00
|
|
|
spv_operand_pattern_t spvAlternatePatternFollowingImmediate(
|
|
|
|
const spv_operand_pattern_t& pattern);
|
2015-09-28 21:04:39 +00:00
|
|
|
|
2016-01-15 16:25:11 +00:00
|
|
|
// Is the operand an ID?
|
|
|
|
bool spvIsIdType(spv_operand_type_t type);
|
|
|
|
|
2018-11-26 22:06:21 +00:00
|
|
|
// Is the operand an input ID?
|
|
|
|
bool spvIsInIdType(spv_operand_type_t type);
|
|
|
|
|
2017-08-09 18:01:12 +00:00
|
|
|
// Takes the opcode of an instruction and returns
|
|
|
|
// a function object that will return true if the index
|
|
|
|
// of the operand can be forward declared. This function will
|
|
|
|
// used in the SSA validation stage of the pipeline
|
|
|
|
std::function<bool(unsigned)> spvOperandCanBeForwardDeclaredFunction(
|
2022-11-04 21:27:10 +00:00
|
|
|
spv::Op opcode);
|
2017-08-09 18:01:12 +00:00
|
|
|
|
2020-01-23 22:04:30 +00:00
|
|
|
// Takes the instruction key of a debug info extension instruction
|
|
|
|
// and returns a function object that will return true if the index
|
|
|
|
// of the operand can be forward declared. This function will
|
|
|
|
// used in the SSA validation stage of the pipeline
|
|
|
|
std::function<bool(unsigned)> spvDbgInfoExtOperandCanBeForwardDeclaredFunction(
|
|
|
|
spv_ext_inst_type_t ext_type, uint32_t key);
|
|
|
|
|
2018-08-03 12:05:33 +00:00
|
|
|
#endif // SOURCE_OPERAND_H_
|