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
9dbca316aa
SPIRV-Tools/test/fuzz/transformation_vector_shuffle_test.cpp

807 lines
34 KiB
C++
Raw Normal View History

spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Copyright (c) 2019 Google LLC
//
// 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
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// 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.
#include "source/fuzz/transformation_vector_shuffle.h"
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
#include "gtest/gtest.h"
#include "source/fuzz/fuzzer_util.h"
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
#include "source/fuzz/instruction_descriptor.h"
#include "test/fuzz/fuzz_test_util.h"
namespace spvtools {
namespace fuzz {
namespace {
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
TEST(TransformationVectorShuffleTest, BasicTest) {
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
std::string shader = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main"
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 310
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeBool
%7 = OpTypeVector %6 2
%10 = OpConstantTrue %6
%11 = OpConstantFalse %6
%12 = OpConstantComposite %7 %10 %11
%112 = OpUndef %7
%13 = OpTypeVector %6 3
%16 = OpConstantComposite %13 %10 %11 %10
%17 = OpTypeVector %6 4
%20 = OpConstantComposite %17 %10 %11 %10 %11
%21 = OpTypeInt 32 1
%22 = OpTypeVector %21 2
%25 = OpConstant %21 1
%26 = OpConstant %21 0
%27 = OpConstantComposite %22 %25 %26
%28 = OpTypeVector %21 3
%31 = OpConstantComposite %28 %25 %26 %25
%32 = OpTypeVector %21 4
%33 = OpTypePointer Function %32
%35 = OpConstantComposite %32 %25 %26 %25 %26
%36 = OpTypeInt 32 0
%37 = OpTypeVector %36 2
%40 = OpConstant %36 1
%41 = OpConstant %36 0
%42 = OpConstantComposite %37 %40 %41
%43 = OpTypeVector %36 3
%46 = OpConstantComposite %43 %40 %41 %40
%47 = OpTypeVector %36 4
%50 = OpConstantComposite %47 %40 %41 %40 %41
%51 = OpTypeFloat 32
%55 = OpConstant %51 1
%56 = OpConstant %51 0
%58 = OpTypeVector %51 3
%61 = OpConstantComposite %58 %55 %56 %55
%62 = OpTypeVector %51 4
%65 = OpConstantComposite %62 %55 %56 %55 %56
%4 = OpFunction %2 None %3
%5 = OpLabel
OpSelectionMerge %100 None
OpBranchConditional %10 %101 %102
%101 = OpLabel
%103 = OpCompositeConstruct %62 %55 %55 %55 %56
OpBranch %100
%102 = OpLabel
OpBranch %100
%100 = OpLabel
OpReturn
OpFunctionEnd
)";
const auto env = SPV_ENV_UNIVERSAL_1_4;
const auto consumer = nullptr;
const auto context = BuildModule(env, consumer, shader, kFuzzAssembleOption);
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
spvtools::ValidatorOptions validator_options;
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
TransformationContext transformation_context(
MakeUnique<FactManager>(context.get()), validator_options);
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(10, {}), MakeDataDescriptor(12, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(11, {}), MakeDataDescriptor(12, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(10, {}), MakeDataDescriptor(16, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(11, {}), MakeDataDescriptor(16, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(10, {}), MakeDataDescriptor(16, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(10, {}), MakeDataDescriptor(20, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(11, {}), MakeDataDescriptor(20, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(10, {}), MakeDataDescriptor(20, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(11, {}), MakeDataDescriptor(20, {3}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(25, {}), MakeDataDescriptor(27, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(26, {}), MakeDataDescriptor(27, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(25, {}), MakeDataDescriptor(31, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(26, {}), MakeDataDescriptor(31, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(25, {}), MakeDataDescriptor(31, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(25, {}), MakeDataDescriptor(35, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(26, {}), MakeDataDescriptor(35, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(25, {}), MakeDataDescriptor(35, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(26, {}), MakeDataDescriptor(35, {3}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(40, {}), MakeDataDescriptor(42, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(41, {}), MakeDataDescriptor(42, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(40, {}), MakeDataDescriptor(46, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(41, {}), MakeDataDescriptor(46, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(40, {}), MakeDataDescriptor(46, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(40, {}), MakeDataDescriptor(50, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(41, {}), MakeDataDescriptor(50, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(40, {}), MakeDataDescriptor(50, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(41, {}), MakeDataDescriptor(50, {3}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(55, {}), MakeDataDescriptor(61, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(56, {}), MakeDataDescriptor(61, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(55, {}), MakeDataDescriptor(61, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(55, {}), MakeDataDescriptor(65, {0}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(56, {}), MakeDataDescriptor(65, {1}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(55, {}), MakeDataDescriptor(65, {2}));
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
transformation_context.GetFactManager()->AddFactDataSynonym(
spirv-fuzz: Move IRContext parameter into constructor (#3837) This PR converts IRContext parameter in fact managers into a class field. Part of #3698.
2020-09-24 11:27:59 +00:00
MakeDataDescriptor(56, {}), MakeDataDescriptor(65, {3}));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// %103 does not dominate the return instruction.
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 103, 65,
{3, 5, 7})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Illegal to shuffle a bvec2 and a vec3
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 112, 61,
{0, 2, 4})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Illegal to shuffle an ivec2 and a uvec4
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 27, 50,
{1, 3, 5})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Vector 1 does not exist
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 300, 50,
{1, 3, 5})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Vector 2 does not exist
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 27, 300,
{1, 3, 5})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Index out of range
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {0, 20})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Too many indices
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112,
{0, 1, 0, 1, 0, 1, 0, 1})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Too few indices
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Too few indices again
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {0})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Indices define unknown type: we do not have vec2
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 65, 65, {0, 1})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// The instruction to insert before does not exist
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpCompositeConstruct, 1),
201, 20, 12, {0xFFFFFFFF, 3, 5})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// The 'fresh' id is already in use
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 12, 12, 112, {})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
protobufs::DataDescriptor temp_dd;
TransformationVectorShuffle transformation1(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {1, 0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation1.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation1, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(200, {0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(11, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(200, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(10, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
TransformationVectorShuffle transformation2(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 201, 20, 12,
{0xFFFFFFFF, 3, 5});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation2.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation2, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(201, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(11, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(201, {2});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(11, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
TransformationVectorShuffle transformation3(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 202, 27, 35, {5, 4, 1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation3.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation3, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(202, {0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(26, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(202, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(25, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(202, {2});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(26, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
TransformationVectorShuffle transformation4(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 203, 42, 46, {0, 1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation4.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation4, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(203, {0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(40, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(203, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(41, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
TransformationVectorShuffle transformation5(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 204, 42, 46, {2, 3, 4});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation5.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation5, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(204, {0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(40, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(204, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(41, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(204, {2});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(40, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
TransformationVectorShuffle transformation6(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 205, 42, 42,
{0, 1, 2, 3});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation6.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation6, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(205, {0});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(40, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(205, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(41, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(205, {2});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(40, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(205, {3});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(41, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// swizzle vec4 from vec4 and vec4 using some undefs
TransformationVectorShuffle transformation7(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 206, 65, 65,
{0xFFFFFFFF, 3, 6, 0xFFFFFFFF});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(
transformation7.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation7, context.get(),
&transformation_context);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
temp_dd = MakeDataDescriptor(206, {1});
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
spirv-fuzz: Make handling of synonym facts more efficient (#3301) The fact manager maintains an equivalence relation on data descriptors that tracks when one data descriptor could be used in place of another. An algorithm to compute the closure of such facts allows deducing new synonym facts from existing facts. E.g., for two 2D vectors u and v it is known that u.x is synonymous with v.x and u.y is synonymous with v.y, it can be deduced that u and v are synonymous. The closure computation algorithm is very expensive if we get large equivalence relations. This change addresses this in three ways: - The size of equivalence relations is reduced by limiting the extent to which the components of a composite are recursively noted as being equivalent, so that when we have large synonymous arrays we do not record all array elements as being pairwise equivalent. - When computing the closure of facts, equivalence classes above a certain size are simply skipped (which can lead to missed facts) - The closure computation is performed less frequently - it is invoked explicitly before fuzzer passes that will benefit from data synonym facts. A new transformation is used to control its invocation, so that fuzzing and replaying do not get out of sync. The change also tidies up the order in which some getters are declared in FuzzerContext.
2020-04-20 18:02:49 +00:00
MakeDataDescriptor(56, {}), temp_dd));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
std::string after_transformation = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main"
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 310
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeBool
%7 = OpTypeVector %6 2
%10 = OpConstantTrue %6
%11 = OpConstantFalse %6
%12 = OpConstantComposite %7 %10 %11
%112 = OpUndef %7
%13 = OpTypeVector %6 3
%16 = OpConstantComposite %13 %10 %11 %10
%17 = OpTypeVector %6 4
%20 = OpConstantComposite %17 %10 %11 %10 %11
%21 = OpTypeInt 32 1
%22 = OpTypeVector %21 2
%25 = OpConstant %21 1
%26 = OpConstant %21 0
%27 = OpConstantComposite %22 %25 %26
%28 = OpTypeVector %21 3
%31 = OpConstantComposite %28 %25 %26 %25
%32 = OpTypeVector %21 4
%33 = OpTypePointer Function %32
%35 = OpConstantComposite %32 %25 %26 %25 %26
%36 = OpTypeInt 32 0
%37 = OpTypeVector %36 2
%40 = OpConstant %36 1
%41 = OpConstant %36 0
%42 = OpConstantComposite %37 %40 %41
%43 = OpTypeVector %36 3
%46 = OpConstantComposite %43 %40 %41 %40
%47 = OpTypeVector %36 4
%50 = OpConstantComposite %47 %40 %41 %40 %41
%51 = OpTypeFloat 32
%55 = OpConstant %51 1
%56 = OpConstant %51 0
%58 = OpTypeVector %51 3
%61 = OpConstantComposite %58 %55 %56 %55
%62 = OpTypeVector %51 4
%65 = OpConstantComposite %62 %55 %56 %55 %56
%4 = OpFunction %2 None %3
%5 = OpLabel
OpSelectionMerge %100 None
OpBranchConditional %10 %101 %102
%101 = OpLabel
%103 = OpCompositeConstruct %62 %55 %55 %55 %56
OpBranch %100
%102 = OpLabel
OpBranch %100
%100 = OpLabel
%200 = OpVectorShuffle %7 %12 %112 1 0
%201 = OpVectorShuffle %13 %20 %12 0xFFFFFFFF 3 5
%202 = OpVectorShuffle %28 %27 %35 5 4 1
%203 = OpVectorShuffle %37 %42 %46 0 1
%204 = OpVectorShuffle %43 %42 %46 2 3 4
%205 = OpVectorShuffle %47 %42 %42 0 1 2 3
%206 = OpVectorShuffle %62 %65 %65 0xFFFFFFFF 3 6 0xFFFFFFFF
OpReturn
OpFunctionEnd
)";
ASSERT_TRUE(IsEqual(env, after_transformation, context.get()));
}
TEST(TransformationVectorShuffleTest, IllegalInsertionPoints) {
std::string shader = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main" %51 %27
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 310
OpName %4 "main"
OpName %25 "buf"
OpMemberName %25 0 "value"
OpName %27 ""
OpName %51 "color"
OpMemberDecorate %25 0 Offset 0
OpDecorate %25 Block
OpDecorate %27 DescriptorSet 0
OpDecorate %27 Binding 0
OpDecorate %51 Location 0
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeFloat 32
%7 = OpTypeVector %6 4
%150 = OpTypeVector %6 2
%10 = OpConstant %6 0.300000012
%11 = OpConstant %6 0.400000006
%12 = OpConstant %6 0.5
%13 = OpConstant %6 1
%14 = OpConstantComposite %7 %10 %11 %12 %13
%15 = OpTypeInt 32 1
%18 = OpConstant %15 0
%25 = OpTypeStruct %6
%26 = OpTypePointer Uniform %25
%27 = OpVariable %26 Uniform
%28 = OpTypePointer Uniform %6
%32 = OpTypeBool
%103 = OpConstantTrue %32
%34 = OpConstant %6 0.100000001
%48 = OpConstant %15 1
%50 = OpTypePointer Output %7
%51 = OpVariable %50 Output
%100 = OpTypePointer Function %6
%4 = OpFunction %2 None %3
%5 = OpLabel
%101 = OpVariable %100 Function
%102 = OpVariable %100 Function
OpBranch %19
%19 = OpLabel
%60 = OpPhi %7 %14 %5 %58 %20
%59 = OpPhi %15 %18 %5 %49 %20
%29 = OpAccessChain %28 %27 %18
%30 = OpLoad %6 %29
%31 = OpConvertFToS %15 %30
%33 = OpSLessThan %32 %59 %31
OpLoopMerge %21 %20 None
OpBranchConditional %33 %20 %21
%20 = OpLabel
%39 = OpCompositeExtract %6 %60 0
%40 = OpFAdd %6 %39 %34
%55 = OpCompositeInsert %7 %40 %60 0
%44 = OpCompositeExtract %6 %60 1
%45 = OpFSub %6 %44 %34
%58 = OpCompositeInsert %7 %45 %55 1
%49 = OpIAdd %15 %59 %48
OpBranch %19
%21 = OpLabel
OpStore %51 %60
OpSelectionMerge %105 None
OpBranchConditional %103 %104 %105
%104 = OpLabel
OpBranch %105
%105 = OpLabel
OpReturn
OpFunctionEnd
)";
const auto env = SPV_ENV_UNIVERSAL_1_4;
const auto consumer = nullptr;
const auto context = BuildModule(env, consumer, shader, kFuzzAssembleOption);
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
spvtools::ValidatorOptions validator_options;
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
TransformationContext transformation_context(
MakeUnique<FactManager>(context.get()), validator_options);
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Cannot insert before the OpVariables of a function.
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(101, SpvOpVariable, 0), 200, 14, 14, {0, 1})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(101, SpvOpVariable, 1), 200, 14, 14, {1, 2})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(102, SpvOpVariable, 0), 200, 14, 14, {1, 2})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// OK to insert right after the OpVariables.
ASSERT_FALSE(
TransformationVectorShuffle(
MakeInstructionDescriptor(102, SpvOpBranch, 1), 200, 14, 14, {1, 1})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Cannot insert before the OpPhis of a block.
ASSERT_FALSE(
TransformationVectorShuffle(MakeInstructionDescriptor(60, SpvOpPhi, 0),
200, 14, 14, {2, 0})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
ASSERT_FALSE(
TransformationVectorShuffle(MakeInstructionDescriptor(59, SpvOpPhi, 0),
200, 14, 14, {3, 0})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// OK to insert after the OpPhis.
ASSERT_TRUE(TransformationVectorShuffle(
MakeInstructionDescriptor(59, SpvOpAccessChain, 0), 200, 14,
14, {3, 4})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Cannot insert before OpLoopMerge
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(33, SpvOpBranchConditional, 0),
200, 14, 14, {3})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
// Cannot insert before OpSelectionMerge
ASSERT_FALSE(TransformationVectorShuffle(
MakeInstructionDescriptor(21, SpvOpBranchConditional, 0),
200, 14, 14, {2})
spirv-fuzz: Introduce TransformationContext (#3272) Some transformations (e.g. TransformationAddFunction) rely on running the validator to decide whether the transformation is applicable. A recent change allowed spirv-fuzz to take validator options, to cater for the case where a module should be considered valid under particular conditions. However, validation during the checking of transformations had no access to these validator options. This change introduced TransformationContext, which currently consists of a fact manager and a set of validator options, but could in the future have other fields corresponding to other objects that it is useful to have access to when applying transformations. Now, instead of checking and applying transformations in the context of a FactManager, a TransformationContext is used. This gives access to the fact manager as before, and also access to the validator options when they are needed.
2020-04-02 14:54:46 +00:00
.IsApplicable(context.get(), transformation_context));
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
}
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
TEST(TransformationVectorShuffleTest, HandlesIrrelevantIds1) {
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
std::string shader = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main"
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 310
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeBool
%7 = OpTypeVector %6 2
%10 = OpConstantTrue %6
%11 = OpConstantFalse %6
%12 = OpConstantComposite %7 %10 %11
%112 = OpConstantComposite %7 %11 %10
%13 = OpTypeVector %6 3
%16 = OpConstantComposite %13 %10 %11 %10
%17 = OpTypeVector %6 4
%20 = OpConstantComposite %17 %10 %11 %10 %11
%21 = OpTypeInt 32 1
%22 = OpTypeVector %21 2
%25 = OpConstant %21 1
%26 = OpConstant %21 0
%27 = OpConstantComposite %22 %25 %26
%28 = OpTypeVector %21 3
%31 = OpConstantComposite %28 %25 %26 %25
%32 = OpTypeVector %21 4
%33 = OpTypePointer Function %32
%35 = OpConstantComposite %32 %25 %26 %25 %26
%36 = OpTypeInt 32 0
%37 = OpTypeVector %36 2
%40 = OpConstant %36 1
%41 = OpConstant %36 0
%42 = OpConstantComposite %37 %40 %41
%43 = OpTypeVector %36 3
%46 = OpConstantComposite %43 %40 %41 %40
%47 = OpTypeVector %36 4
%50 = OpConstantComposite %47 %40 %41 %40 %41
%51 = OpTypeFloat 32
%55 = OpConstant %51 1
%56 = OpConstant %51 0
%58 = OpTypeVector %51 3
%61 = OpConstantComposite %58 %55 %56 %55
%62 = OpTypeVector %51 4
%65 = OpConstantComposite %62 %55 %56 %55 %56
%4 = OpFunction %2 None %3
%5 = OpLabel
OpSelectionMerge %100 None
OpBranchConditional %10 %101 %102
%101 = OpLabel
%103 = OpCompositeConstruct %62 %55 %55 %55 %56
OpBranch %100
%102 = OpLabel
OpBranch %100
%100 = OpLabel
OpReturn
OpFunctionEnd
)";
const auto env = SPV_ENV_UNIVERSAL_1_4;
const auto consumer = nullptr;
const auto context = BuildModule(env, consumer, shader, kFuzzAssembleOption);
spvtools::ValidatorOptions validator_options;
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
TransformationContext transformation_context(
MakeUnique<FactManager>(context.get()), validator_options);
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
TransformationVectorShuffle transformation(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {2, 0});
ASSERT_TRUE(
transformation.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation, context.get(), &transformation_context);
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(12, {0}), MakeDataDescriptor(200, {1})));
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(112, {0}), MakeDataDescriptor(200, {0})));
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
}
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
TEST(TransformationVectorShuffleTest, HandlesIrrelevantIds2) {
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
std::string shader = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main"
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 310
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeBool
%7 = OpTypeVector %6 2
%10 = OpConstantTrue %6
%11 = OpConstantFalse %6
%12 = OpConstantComposite %7 %10 %11
%112 = OpConstantComposite %7 %11 %10
%13 = OpTypeVector %6 3
%16 = OpConstantComposite %13 %10 %11 %10
%17 = OpTypeVector %6 4
%20 = OpConstantComposite %17 %10 %11 %10 %11
%21 = OpTypeInt 32 1
%22 = OpTypeVector %21 2
%25 = OpConstant %21 1
%26 = OpConstant %21 0
%27 = OpConstantComposite %22 %25 %26
%28 = OpTypeVector %21 3
%31 = OpConstantComposite %28 %25 %26 %25
%32 = OpTypeVector %21 4
%33 = OpTypePointer Function %32
%35 = OpConstantComposite %32 %25 %26 %25 %26
%36 = OpTypeInt 32 0
%37 = OpTypeVector %36 2
%40 = OpConstant %36 1
%41 = OpConstant %36 0
%42 = OpConstantComposite %37 %40 %41
%43 = OpTypeVector %36 3
%46 = OpConstantComposite %43 %40 %41 %40
%47 = OpTypeVector %36 4
%50 = OpConstantComposite %47 %40 %41 %40 %41
%51 = OpTypeFloat 32
%55 = OpConstant %51 1
%56 = OpConstant %51 0
%58 = OpTypeVector %51 3
%61 = OpConstantComposite %58 %55 %56 %55
%62 = OpTypeVector %51 4
%65 = OpConstantComposite %62 %55 %56 %55 %56
%4 = OpFunction %2 None %3
%5 = OpLabel
OpSelectionMerge %100 None
OpBranchConditional %10 %101 %102
%101 = OpLabel
%103 = OpCompositeConstruct %62 %55 %55 %55 %56
OpBranch %100
%102 = OpLabel
OpBranch %100
%100 = OpLabel
OpReturn
OpFunctionEnd
)";
const auto env = SPV_ENV_UNIVERSAL_1_4;
const auto consumer = nullptr;
const auto context = BuildModule(env, consumer, shader, kFuzzAssembleOption);
spvtools::ValidatorOptions validator_options;
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
TransformationContext transformation_context(
MakeUnique<FactManager>(context.get()), validator_options);
transformation_context.GetFactManager()->AddFactIdIsIrrelevant(112);
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
TransformationVectorShuffle transformation(
MakeInstructionDescriptor(100, SpvOpReturn, 0), 200, 12, 112, {2, 0});
ASSERT_TRUE(
transformation.IsApplicable(context.get(), transformation_context));
spirv-fuzz: Report fresh ids in transformations (#3856) Adds a virtual method, GetFreshIds(), to Transformation. Every transformation uses this to indicate which ids in its protobuf message are fresh ids. This means that when replaying a sequence of transformations the replayer can obtain a smallest id that is not in use by the module already and that will not be used by any transformation by necessity. Ids greater than or equal to this id can be used as overflow ids. Fixes #3851.
2020-09-29 21:12:49 +00:00
ApplyAndCheckFreshIds(transformation, context.get(), &transformation_context);
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
// Because %12 is not irrelevant, we get a synonym between it and %200[1].
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(12, {0}), MakeDataDescriptor(200, {1})));
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
// Because %112 is irrelevant, we do not get a synonym between it and %200[0].
spirv-fuzz: Use unique_ptr<FactManager> in TransformationContext (#3844) TransformationContext now holds a std::unique_ptr to a FactManager, rather than a plain pointer. This makes it easier for clients of TransformationContext to work with heap-allocated instances of TransformationContext, which is needed in some upcoming work.
2020-09-24 16:28:49 +00:00
ASSERT_FALSE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(112, {0}), MakeDataDescriptor(200, {0})));
spirv-fuzz: Test usages of IdIsIrrelevant fact (#3578) Part of #3177. Fixes #3579.
2020-07-23 16:19:13 +00:00
}
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
TEST(TransformationVectorShuffleTest, HandlesIrrelevantIds3) {
std::string shader = R"(
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "main"
OpExecutionMode %4 OriginUpperLeft
OpSource ESSL 320
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeInt 32 1
%7 = OpTypeVector %6 2
%8 = OpTypePointer Function %7
%10 = OpConstant %6 0
%11 = OpConstant %6 1
%12 = OpConstantComposite %7 %10 %11
%40 = OpConstantComposite %7 %10 %11
%13 = OpTypeBool
%14 = OpConstantFalse %13
%4 = OpFunction %2 None %3
%5 = OpLabel
%9 = OpVariable %8 Function
OpStore %9 %12
OpSelectionMerge %16 None
OpBranchConditional %14 %15 %16
%15 = OpLabel
OpBranch %16
%16 = OpLabel
OpReturn
OpFunctionEnd
)";
const auto env = SPV_ENV_UNIVERSAL_1_4;
const auto consumer = nullptr;
const auto context = BuildModule(env, consumer, shader, kFuzzAssembleOption);
spvtools::ValidatorOptions validator_options;
spirv-fuzz: Fix to TransformationInlineFunction (#3913) This fixes a problem where TransformationInlineFunction could lead to distinct instructions having identical unique ids. It adds a validity check to detect this problem in general. Fixes #3911.
2020-10-16 21:58:09 +00:00
ASSERT_TRUE(fuzzerutil::IsValidAndWellFormed(context.get(), validator_options,
kConsoleMessageConsumer));
spirv-fuzz: Do not add synonyms involving irrelevant ids (#3890) Fixes #3886.
2020-10-08 21:34:39 +00:00
TransformationContext transformation_context(
MakeUnique<FactManager>(context.get()), validator_options);
transformation_context.GetFactManager()->AddFactIdIsIrrelevant(40);
transformation_context.GetFactManager()->AddFactBlockIsDead(15);
TransformationVectorShuffle transformation1(
MakeInstructionDescriptor(15, SpvOpBranch, 0), 200, 12, 12, {0, 3});
ASSERT_TRUE(
transformation1.IsApplicable(context.get(), transformation_context));
ApplyAndCheckFreshIds(transformation1, context.get(),
&transformation_context);
ASSERT_FALSE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(200, {0}), MakeDataDescriptor(12, {0})));
ASSERT_FALSE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(200, {1}), MakeDataDescriptor(12, {1})));
TransformationVectorShuffle transformation2(
MakeInstructionDescriptor(16, SpvOpReturn, 0), 201, 12, 40, {0, 1});
ASSERT_TRUE(
transformation2.IsApplicable(context.get(), transformation_context));
ApplyAndCheckFreshIds(transformation2, context.get(),
&transformation_context);
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(201, {0}), MakeDataDescriptor(12, {0})));
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(201, {1}), MakeDataDescriptor(12, {1})));
TransformationVectorShuffle transformation3(
MakeInstructionDescriptor(16, SpvOpReturn, 0), 202, 40, 12, {2, 3});
ASSERT_TRUE(
transformation3.IsApplicable(context.get(), transformation_context));
ApplyAndCheckFreshIds(transformation3, context.get(),
&transformation_context);
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(202, {0}), MakeDataDescriptor(12, {0})));
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(202, {1}), MakeDataDescriptor(12, {1})));
TransformationVectorShuffle transformation4(
MakeInstructionDescriptor(16, SpvOpReturn, 0), 203, 40, 12, {0, 3});
ASSERT_TRUE(
transformation4.IsApplicable(context.get(), transformation_context));
ApplyAndCheckFreshIds(transformation4, context.get(),
&transformation_context);
// Because %40 is irrelevant we do not get a synonym between it and %203[0].
ASSERT_FALSE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(203, {0}), MakeDataDescriptor(40, {0})));
// Because %12 is *not* irrelevant we do get a synonym between it and %203[1].
ASSERT_TRUE(transformation_context.GetFactManager()->IsSynonymous(
MakeDataDescriptor(203, {1}), MakeDataDescriptor(12, {1})));
}
spirv-fuzz: vector shuffle transformation (#3015) Inroduces a new transformation that adds a vector shuffle instruction to the module, with associated facts about how the result vector of the shuffle relates to the input vectors. A fuzzer pass to add such transformations is not yet in place.
2019-11-06 17:11:54 +00:00
} // namespace
} // namespace fuzz
} // namespace spvtools
Reference in New Issue Copy Permalink