[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
//===-- SnippetGeneratorTest.cpp --------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "SnippetGenerator.h"
|
|
|
|
#include "gmock/gmock.h"
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
#include <initializer_list>
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
namespace exegesis {
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, Square) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0, 1}, {2, 3}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 2},
|
|
|
|
{0, 3},
|
|
|
|
{1, 2},
|
|
|
|
{1, 3},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, MiddleColumn) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0}, {1, 2}, {3}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 1, 3},
|
|
|
|
{0, 2, 3},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, SideColumns) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0, 1}, {2}, {3, 4}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 2, 3},
|
|
|
|
{0, 2, 4},
|
|
|
|
{1, 2, 3},
|
|
|
|
{1, 2, 4},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, LeftColumn) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0, 1}, {2}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 2},
|
|
|
|
{1, 2},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, RightColumn) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0}, {1, 2}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 1},
|
|
|
|
{0, 2},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, Column) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0, 1}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0},
|
|
|
|
{1},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, Row) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0}, {1}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0, 1},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(CombinationGenerator, Singleton) {
|
|
|
|
const std::vector<std::vector<int>> Choices{{0}};
|
|
|
|
|
|
|
|
std::vector<std::vector<int>> Variants;
|
2020-02-12 21:30:22 +01:00
|
|
|
CombinationGenerator<int, std::vector<int>, 4> G(Choices);
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
const size_t NumVariants = G.numCombinations();
|
2020-02-12 21:30:22 +01:00
|
|
|
G.generate([&](ArrayRef<int> State) -> bool {
|
|
|
|
Variants.emplace_back(State);
|
|
|
|
return false; // keep going
|
|
|
|
});
|
[llvm-exegesis] Exploring X86::OperandType::OPERAND_COND_CODE
Summary:
Currently, we only have nice exploration for LEA instruction,
while for the rest, we rely on `randomizeUnsetVariables()`
to sometimes generate something interesting.
While that works, it isn't very reliable in coverage :)
Here, i'm making an assumption that while we may want to explore
multi-instruction configs, we are most interested in the
characteristics of the main instruction we were asked about.
Which we can do, by taking the existing `randomizeMCOperand()`,
and turning it on it's head - instead of relying on it to randomly fill
one of the interesting values, let's pregenerate all the possible interesting
values for the variable, and then generate as much `InstructionTemplate`
combinations of these possible values for variables as needed/possible.
Of course, that requires invasive changes to no longer pass just the
naked `Instruction`, but sometimes partially filled `InstructionTemplate`.
As it can be seen from the test, this allows us to explore
`X86::OperandType::OPERAND_COND_CODE` for instructions
that take such an operand.
I'm hoping this will greatly simplify exploration.
Reviewers: courbet, gchatelet
Reviewed By: gchatelet
Subscribers: orodley, mgorny, sdardis, tschuett, jrtc27, atanasyan, mstojanovic, andreadb, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74156
2020-02-12 18:54:39 +01:00
|
|
|
|
|
|
|
const std::vector<std::vector<int>> ExpectedVariants{
|
|
|
|
{0},
|
|
|
|
};
|
|
|
|
ASSERT_THAT(Variants, ::testing::SizeIs(NumVariants));
|
|
|
|
ASSERT_THAT(Variants, ::testing::ContainerEq(ExpectedVariants));
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
} // namespace exegesis
|
|
|
|
} // namespace llvm
|