RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 03:33:20 +01:00
Code Issues Projects Releases Wiki Activity
17ccae5b61
llvm-mirror/unittests/Support/OptimizedStructLayoutTest.cpp

132 lines
3.3 KiB
C++
Raw Normal View History

Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
//=== - unittest/Support/OptimizedStructLayoutTest.cpp - Layout tests -----===//
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
//
// 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
//
//===----------------------------------------------------------------------===//
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
#include "llvm/Support/OptimizedStructLayout.h"
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
#include "gtest/gtest.h"
using namespace llvm;
namespace {
class LayoutTest {
struct Field {
uint64_t Size;
Align Alignment;
uint64_t ForcedOffset;
uint64_t ExpectedOffset;
};
SmallVector<Field, 16> Fields;
bool Verified = false;
public:
LayoutTest() {}
LayoutTest(const LayoutTest &) = delete;
LayoutTest &operator=(const LayoutTest &) = delete;
~LayoutTest() { assert(Verified); }
LayoutTest &flexible(uint64_t Size, uint64_t Alignment,
uint64_t ExpectedOffset) {
Fields.push_back({Size, Align(Alignment),
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
OptimizedStructLayoutField::FlexibleOffset, ExpectedOffset});
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
return *this;
}
LayoutTest &fixed(uint64_t Size, uint64_t Alignment, uint64_t Offset) {
Fields.push_back({Size, Align(Alignment), Offset, Offset});
return *this;
}
void verify(uint64_t ExpectedSize, uint64_t ExpectedAlignment) {
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
SmallVector<OptimizedStructLayoutField, 8> LayoutFields;
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
LayoutFields.reserve(Fields.size());
for (auto &F : Fields)
LayoutFields.emplace_back(&F, F.Size, F.Alignment, F.ForcedOffset);
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
auto SizeAndAlign = performOptimizedStructLayout(LayoutFields);
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
EXPECT_EQ(SizeAndAlign.first, ExpectedSize);
EXPECT_EQ(SizeAndAlign.second, Align(ExpectedAlignment));
for (auto &LF : LayoutFields) {
auto &F = *static_cast<const Field *>(LF.Id);
EXPECT_EQ(LF.Offset, F.ExpectedOffset);
}
Verified = true;
}
};
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, Basic) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
LayoutTest()
.flexible(12, 4, 8)
.flexible(8, 8, 0)
.flexible(4, 4, 20)
.verify(24, 8);
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, OddSize) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
LayoutTest()
.flexible(8, 8, 16)
.flexible(4, 4, 12)
.flexible(1, 1, 10)
.flexible(10, 8, 0)
.verify(24, 8);
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, Gaps) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
LayoutTest()
.fixed(4, 4, 8)
.fixed(4, 4, 16)
.flexible(4, 4, 0)
.flexible(4, 4, 4)
.flexible(4, 4, 12)
.flexible(4, 4, 20)
.verify(24, 4);
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, Greed) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
// The greedy algorithm doesn't find the optimal layout here, which
// would be to put the 5-byte field at the end.
LayoutTest()
.fixed(4, 4, 8)
.flexible(5, 4, 0)
.flexible(4, 4, 12)
.flexible(4, 4, 16)
.flexible(4, 4, 20)
.verify(24, 4);
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, Jagged) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
LayoutTest()
.flexible(1, 2, 18)
.flexible(13, 8, 0)
.flexible(3, 2, 14)
.verify(19, 8);
}
Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 06:13:49 +02:00
TEST(OptimizedStructLayoutTest, GardenPath) {
Add an algorithm for performing "optimal" layout of a struct. The algorithm supports both assigning a fixed offset to a field prior to layout and allowing fields to have sizes that aren't multiples of their required alignments. This means that the well-known algorithm of sorting by decreasing alignment isn't always good enough. Still, we start with that, and only if that leaves padding around do we fall back on a greedy padding-minimizing algorithm. There is no known efficient algorithm for producing a guaranteed-minimal layout in all cases. In fact, allowing arbitrary fixed-offset fields means there's a straightforward reduction from bin-packing, making this NP-hard. But as usual with such problems, we can still efficiently produce adequate solutions to the cases that matter most to us. I intend to use this in coroutine frame layout, where the retcon lowerings very badly want to minimize total space usage, and where the switch lowering can indeed produce a header with interior padding if the promise field is highly-aligned. But it may be useful in a much wider variety of situations.
2020-03-20 21:45:39 +01:00
// The 4-byte-aligned field is our highest priority, but the less-aligned
// fields keep leaving the end offset mis-aligned.
LayoutTest()
.fixed(7, 4, 0)
.flexible(4, 4, 44)
.flexible(6, 1, 7)
.flexible(5, 1, 13)
.flexible(7, 2, 18)
.flexible(4, 1, 25)
.flexible(4, 1, 29)
.flexible(1, 1, 33)
.flexible(4, 2, 34)
.flexible(4, 2, 38)
.flexible(2, 2, 42)
.flexible(2, 2, 48)
.verify(50, 4);
}
Reference in New Issue Copy Permalink