maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/unittests/Support/OptimizedStructLayoutTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

150 lines
3.8 KiB
C++
Raw Normal View History

Rename OptimalLayout to OptimizedStructLayout at Chris's request.
2020-04-10 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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 12:13:49 +08: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-21 04:45:39 +08: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);
Fix a bug in OptimizedStructLayout when filling gaps before fixed fields with highly-aligned flexible fields. The code was not considering the possibility that aligning the current offset to the alignment of a queue might push us past the end of the gap. Subtracting the offsets to figure out the maximum field size for the gap then overflowed, making us think that we had nearly unbounded space to fill. Fixes PR 51131.
2021-07-22 03:39:42 +08:00
}
// PR 51131
TEST(OptimizedStructLayoutTest, HighAlignment) {
// Handle the case where a flexible field has such a high alignment
// requirement that aligning LastEnd to it gives an offset past the
// end of the gap before the next fixed-alignment field.
LayoutTest()
.fixed(8, 8, 0)
.fixed(8, 8, 8)
.fixed(64, 64, 64)
.flexible(1, 1, 16)
.flexible(1, 1, 17)
.flexible(4, 128, 128)
.flexible(1, 1, 18)
.flexible(1, 1, 19)
.verify(132, 128);
}