RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-19 19:12:56 +02:00
Code Issues Projects Releases Wiki Activity
bdf55580f6
llvm-mirror/lib/CodeGen/AsmPrinter/AccelTable.cpp

722 lines
25 KiB
C++
Raw Normal View History

[NFC] Rename DwarfAccelTable and move header. This patch renames DwarfAccelTable.{h,cpp} to AccelTable.{h,cpp} and moves the header to the include dir so it is accessible by the dsymutil implementation. Differential revision: https://reviews.llvm.org/D42529 llvm-svn: 323654
2018-01-29 15:52:41 +01:00
//===- llvm/CodeGen/AsmPrinter/AccelTable.cpp - Accelerator Tables --------===//
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
[NFC] Rename DwarfAccelTable and move header. This patch renames DwarfAccelTable.{h,cpp} to AccelTable.{h,cpp} and moves the header to the include dir so it is accessible by the dsymutil implementation. Differential revision: https://reviews.llvm.org/D42529 llvm-svn: 323654
2018-01-29 15:52:41 +01:00
// This file contains support for writing accelerator tables.
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
//
//===----------------------------------------------------------------------===//
[NFC] Rename DwarfAccelTable and move header. This patch renames DwarfAccelTable.{h,cpp} to AccelTable.{h,cpp} and moves the header to the include dir so it is accessible by the dsymutil implementation. Differential revision: https://reviews.llvm.org/D42529 llvm-svn: 323654
2018-01-29 15:52:41 +01:00
#include "llvm/CodeGen/AccelTable.h"
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
#include "DwarfCompileUnit.h"
No need to do an expensive stable sort for a bunch of integers. llvm-svn: 153438
2012-03-26 16:17:26 +02:00
#include "llvm/ADT/STLExtras.h"
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
#include "llvm/ADT/StringMap.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-03 17:50:05 +01:00
#include "llvm/ADT/Twine.h"
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
#include "llvm/BinaryFormat/Dwarf.h"
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
#include "llvm/CodeGen/AsmPrinter.h"
Make DIE.h a public CodeGen header. dsymutil would like to use all the AsmPrinter/MCStreamer infrastructure to stream out the DWARF. In order to do so, it will reuse the DIE object and so this header needs to be public. The interface exposed here has some corners that cannot be used without a DwarfDebug object, but clients that want to stream Dwarf can just avoid these. Differential Revision: http://reviews.llvm.org/D6695 llvm-svn: 225208
2015-01-05 22:29:41 +01:00
#include "llvm/CodeGen/DIE.h"
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
#include "llvm/MC/MCExpr.h"
#include "llvm/MC/MCStreamer.h"
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
#include "llvm/MC/MCSymbol.h"
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
#include "llvm/Support/raw_ostream.h"
#include <algorithm>
#include <cstddef>
#include <cstdint>
#include <limits>
#include <vector>
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
using namespace llvm;
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
void AccelTableBase::computeBucketCount() {
// First get the number of unique hashes.
std::vector<uint32_t> Uniques;
Uniques.reserve(Entries.size());
for (const auto &E : Entries)
Uniques.push_back(E.second.HashValue);
array_pod_sort(Uniques.begin(), Uniques.end());
std::vector<uint32_t>::iterator P =
std::unique(Uniques.begin(), Uniques.end());
UniqueHashCount = std::distance(Uniques.begin(), P);
if (UniqueHashCount > 1024)
BucketCount = UniqueHashCount / 4;
else if (UniqueHashCount > 16)
BucketCount = UniqueHashCount / 2;
else
BucketCount = std::max<uint32_t>(UniqueHashCount, 1);
}
void AccelTableBase::finalize(AsmPrinter *Asm, StringRef Prefix) {
// Create the individual hash data outputs.
for (auto &E : Entries) {
// Unique the entries.
std::stable_sort(E.second.Values.begin(), E.second.Values.end(),
[](const AccelTableData *A, const AccelTableData *B) {
return *A < *B;
});
E.second.Values.erase(
std::unique(E.second.Values.begin(), E.second.Values.end()),
E.second.Values.end());
}
// Figure out how many buckets we need, then compute the bucket contents and
// the final ordering. The hashes and offsets can be emitted by walking these
// data structures. We add temporary symbols to the data so they can be
// referenced when emitting the offsets.
computeBucketCount();
// Compute bucket contents and final ordering.
Buckets.resize(BucketCount);
for (auto &E : Entries) {
uint32_t Bucket = E.second.HashValue % BucketCount;
Buckets[Bucket].push_back(&E.second);
E.second.Sym = Asm->createTempSymbol(Prefix);
}
// Sort the contents of the buckets by hash value so that hash collisions end
// up together. Stable sort makes testing easier and doesn't cost much more.
for (auto &Bucket : Buckets)
std::stable_sort(Bucket.begin(), Bucket.end(),
[](HashData *LHS, HashData *RHS) {
return LHS->HashValue < RHS->HashValue;
});
}
namespace {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
/// Base class for writing out Accelerator tables. It holds the common
/// functionality for the two Accelerator table types.
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
class AccelTableWriter {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
protected:
AsmPrinter *const Asm; ///< Destination.
const AccelTableBase &Contents; ///< Data to emit.
/// Controls whether to emit duplicate hash and offset table entries for names
/// with identical hashes. Apple tables don't emit duplicate entries, DWARF v5
/// tables do.
const bool SkipIdenticalHashes;
void emitHashes() const;
/// Emit offsets to lists of entries with identical names. The offsets are
/// relative to the Base argument.
void emitOffsets(const MCSymbol *Base) const;
public:
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
AccelTableWriter(AsmPrinter *Asm, const AccelTableBase &Contents,
bool SkipIdenticalHashes)
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
: Asm(Asm), Contents(Contents), SkipIdenticalHashes(SkipIdenticalHashes) {
}
};
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
class AppleAccelTableWriter : public AccelTableWriter {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
using Atom = AppleAccelTableData::Atom;
/// The fixed header of an Apple Accelerator Table.
struct Header {
uint32_t Magic = MagicHash;
uint16_t Version = 1;
uint16_t HashFunction = dwarf::DW_hash_function_djb;
uint32_t BucketCount;
uint32_t HashCount;
uint32_t HeaderDataLength;
/// 'HASH' magic value to detect endianness.
static const uint32_t MagicHash = 0x48415348;
Header(uint32_t BucketCount, uint32_t UniqueHashCount, uint32_t DataLength)
: BucketCount(BucketCount), HashCount(UniqueHashCount),
HeaderDataLength(DataLength) {}
void emit(AsmPrinter *Asm) const;
#ifndef NDEBUG
void print(raw_ostream &OS) const;
void dump() const { print(dbgs()); }
#endif
};
/// The HeaderData describes the structure of an Apple accelerator table
/// through a list of Atoms.
struct HeaderData {
/// In the case of data that is referenced via DW_FORM_ref_* the offset
/// base is used to describe the offset for all forms in the list of atoms.
uint32_t DieOffsetBase;
const SmallVector<Atom, 4> Atoms;
HeaderData(ArrayRef<Atom> AtomList, uint32_t Offset = 0)
: DieOffsetBase(Offset), Atoms(AtomList.begin(), AtomList.end()) {}
void emit(AsmPrinter *Asm) const;
#ifndef NDEBUG
void print(raw_ostream &OS) const;
void dump() const { print(dbgs()); }
#endif
};
Header Header;
HeaderData HeaderData;
const MCSymbol *SecBegin;
void emitBuckets() const;
void emitData() const;
public:
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
AppleAccelTableWriter(AsmPrinter *Asm, const AccelTableBase &Contents,
ArrayRef<Atom> Atoms, const MCSymbol *SecBegin)
: AccelTableWriter(Asm, Contents, true),
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
Header(Contents.getBucketCount(), Contents.getUniqueHashCount(),
8 + (Atoms.size() * 4)),
HeaderData(Atoms), SecBegin(SecBegin) {}
void emit() const;
#ifndef NDEBUG
void print(raw_ostream &OS) const;
void dump() const { print(dbgs()); }
#endif
};
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
/// Class responsible for emitting a DWARF v5 Accelerator Table. The only
/// public function is emit(), which performs the actual emission.
///
/// The class is templated in its data type. This allows us to emit both dyamic
/// and static data entries. A callback abstract the logic to provide a CU
/// index for a given entry, which is different per data type, but identical
/// for every entry in the same table.
template <typename DataT>
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
class Dwarf5AccelTableWriter : public AccelTableWriter {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
struct Header {
uint32_t UnitLength = 0;
uint16_t Version = 5;
uint16_t Padding = 0;
uint32_t CompUnitCount;
uint32_t LocalTypeUnitCount = 0;
uint32_t ForeignTypeUnitCount = 0;
uint32_t BucketCount;
uint32_t NameCount;
uint32_t AbbrevTableSize = 0;
uint32_t AugmentationStringSize = sizeof(AugmentationString);
char AugmentationString[8] = {'L', 'L', 'V', 'M', '0', '7', '0', '0'};
Header(uint32_t CompUnitCount, uint32_t BucketCount, uint32_t NameCount)
: CompUnitCount(CompUnitCount), BucketCount(BucketCount),
NameCount(NameCount) {}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void emit(const Dwarf5AccelTableWriter &Ctx) const;
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
};
struct AttributeEncoding {
dwarf::Index Index;
dwarf::Form Form;
};
Header Header;
DenseMap<uint32_t, SmallVector<AttributeEncoding, 2>> Abbreviations;
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
ArrayRef<MCSymbol *> CompUnits;
llvm::function_ref<unsigned(const DataT &)> getCUIndexForEntry;
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
MCSymbol *ContributionStart = Asm->createTempSymbol("names_start");
MCSymbol *ContributionEnd = Asm->createTempSymbol("names_end");
MCSymbol *AbbrevStart = Asm->createTempSymbol("names_abbrev_start");
MCSymbol *AbbrevEnd = Asm->createTempSymbol("names_abbrev_end");
MCSymbol *EntryPool = Asm->createTempSymbol("names_entries");
DenseSet<uint32_t> getUniqueTags() const;
// Right now, we emit uniform attributes for all tags.
SmallVector<AttributeEncoding, 2> getUniformAttributes() const;
void emitCUList() const;
void emitBuckets() const;
void emitStringOffsets() const;
void emitAbbrevs() const;
[CodeGen] Fix inconsistent declaration parameter name llvm-svn: 337200
2018-07-16 20:51:40 +02:00
void emitEntry(const DataT &Entry) const;
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
void emitData() const;
public:
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
Dwarf5AccelTableWriter(
AsmPrinter *Asm, const AccelTableBase &Contents,
ArrayRef<MCSymbol *> CompUnits,
llvm::function_ref<unsigned(const DataT &)> GetCUIndexForEntry);
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
void emit() const;
};
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
} // namespace
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AccelTableWriter::emitHashes() const {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
uint64_t PrevHash = std::numeric_limits<uint64_t>::max();
unsigned BucketIdx = 0;
for (auto &Bucket : Contents.getBuckets()) {
for (auto &Hash : Bucket) {
uint32_t HashValue = Hash->HashValue;
if (SkipIdenticalHashes && PrevHash == HashValue)
continue;
Asm->OutStreamer->AddComment("Hash in Bucket " + Twine(BucketIdx));
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(HashValue);
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
PrevHash = HashValue;
}
BucketIdx++;
}
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AccelTableWriter::emitOffsets(const MCSymbol *Base) const {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
const auto &Buckets = Contents.getBuckets();
uint64_t PrevHash = std::numeric_limits<uint64_t>::max();
for (size_t i = 0, e = Buckets.size(); i < e; ++i) {
for (auto *Hash : Buckets[i]) {
uint32_t HashValue = Hash->HashValue;
if (SkipIdenticalHashes && PrevHash == HashValue)
continue;
PrevHash = HashValue;
Asm->OutStreamer->AddComment("Offset in Bucket " + Twine(i));
Asm->EmitLabelDifference(Hash->Sym, Base, sizeof(uint32_t));
}
}
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::Header::emit(AsmPrinter *Asm) const {
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Magic");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(Magic);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Version");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt16(Version);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Hash Function");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt16(HashFunction);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Bucket Count");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(BucketCount);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Hash Count");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(HashCount);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Header Data Length");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(HeaderDataLength);
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
}
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::HeaderData::emit(AsmPrinter *Asm) const {
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("HeaderData Die Offset Base");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(DieOffsetBase);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("HeaderData Atom Count");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(Atoms.size());
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
for (const Atom &A : Atoms) {
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
Asm->OutStreamer->AddComment(dwarf::AtomTypeString(A.Type));
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt16(A.Type);
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
Asm->OutStreamer->AddComment(dwarf::FormEncodingString(A.Form));
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt16(A.Form);
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::emitBuckets() const {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
const auto &Buckets = Contents.getBuckets();
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
unsigned index = 0;
A few more places where we can avoid multiple size queries. llvm-svn: 144099
2011-11-08 19:38:40 +01:00
for (size_t i = 0, e = Buckets.size(); i < e; ++i) {
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Bucket " + Twine(i));
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
if (!Buckets[i].empty())
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(index);
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
else
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(std::numeric_limits<uint32_t>::max());
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
// Buckets point in the list of hashes, not to the data. Do not increment
// the index multiple times in case of hash collisions.
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
uint64_t PrevHash = std::numeric_limits<uint64_t>::max();
DwarfAccelTable: Fix handling of hash collisions. It turns out accelerator tables where totally broken if they contained entries with colliding hashes. The failure mode is pretty bad, as it not only impacted the colliding entries, but would basically make all the entries after the first hash collision pointing in the wrong place. The testcase uses the symbol names that where found to collide during a clang build. From a performance point of view, the patch adds a sort and a linear walk over each bucket contents. While it has a measurable impact on the accelerator table emission, it's not showing up significantly in clang profiles (and I'd argue that correctness is priceless :-)). llvm-svn: 231732
2015-03-10 01:46:31 +01:00
for (auto *HD : Buckets[i]) {
uint32_t HashValue = HD->HashValue;
if (PrevHash != HashValue)
++index;
PrevHash = HashValue;
}
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::emitData() const {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
const auto &Buckets = Contents.getBuckets();
A few more places where we can avoid multiple size queries. llvm-svn: 144099
2011-11-08 19:38:40 +01:00
for (size_t i = 0, e = Buckets.size(); i < e; ++i) {
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
uint64_t PrevHash = std::numeric_limits<uint64_t>::max();
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
for (auto &Hash : Buckets[i]) {
// Terminate the previous entry if there is no hash collision with the
// current one.
[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 311124
2017-08-17 23:26:39 +02:00
if (PrevHash != std::numeric_limits<uint64_t>::max() &&
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
PrevHash != Hash->HashValue)
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(0);
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
// Remember to emit the label for our offset.
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
Asm->OutStreamer->EmitLabel(Hash->Sym);
[CodeGen] Optimize AccelTable Summary: The class contained arrays of two structures (DataArray and HashData). These structures were in 1:1 correspondence, and one of them contained pointers to the other (and *both* contained a "Name" field). By merging these two structures into one, we can save a bit of space without negatively impacting much of anything. Reviewers: JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43073 llvm-svn: 324724
2018-02-09 11:06:56 +01:00
Asm->OutStreamer->AddComment(Hash->Name.getString());
Asm->emitDwarfStringOffset(Hash->Name);
[AsmPrinter] Make AsmPrinter's OutStreamer member a unique_ptr. AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a reference for this is crufty. llvm-svn: 235752
2015-04-24 21:11:51 +02:00
Asm->OutStreamer->AddComment("Num DIEs");
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(Hash->Values.size());
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
for (const auto *V : Hash->Values)
static_cast<const AppleAccelTableData *>(V)->emit(Asm);
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
PrevHash = Hash->HashValue;
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
DwarfAccelTable: Fix handling of hash collisions. It turns out accelerator tables where totally broken if they contained entries with colliding hashes. The failure mode is pretty bad, as it not only impacted the colliding entries, but would basically make all the entries after the first hash collision pointing in the wrong place. The testcase uses the symbol names that where found to collide during a clang build. From a performance point of view, the patch adds a sort and a linear walk over each bucket contents. While it has a measurable impact on the accelerator table emission, it's not showing up significantly in clang profiles (and I'd argue that correctness is priceless :-)). llvm-svn: 231732
2015-03-10 01:46:31 +01:00
// Emit the final end marker for the bucket.
DwarfAccelTable: remove unneeded bucket terminators. Last commit fixed the handling of hash collisions, but it introdcuced unneeded bucket terminators in some places. The generated table was correct, it can just be a tiny bit smaller. As the previous table was correct, the test doesn't need updating. If we really wanted to test this, I could add the section size to the dwarf dump and test for a precise value there. IMO the correctness test is sufficient. llvm-svn: 231748
2015-03-10 04:47:55 +01:00
if (!Buckets[i].empty())
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(0);
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::emit() const {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
Header.emit(Asm);
HeaderData.emit(Asm);
emitBuckets();
emitHashes();
emitOffsets(SecBegin);
emitData();
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::Header::emit(
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
const Dwarf5AccelTableWriter &Ctx) const {
[CodeGen/AccelTable] Don't emit zero-CU name indexes Summary: If an input DICompileUnit is completely empty (e.g., the result of running "clang -g" on an empty file), we don't bother emitting an empty DWARF CU. When we do that, we must make sure we don't also emit a DWARF v5 name index, as DWARF specifies that each index must reference at least one compilation unit. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45435 llvm-svn: 329575
2018-04-09 16:38:53 +02:00
assert(CompUnitCount > 0 && "Index must have at least one CU.");
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
AsmPrinter *Asm = Ctx.Asm;
Asm->OutStreamer->AddComment("Header: unit length");
Asm->EmitLabelDifference(Ctx.ContributionEnd, Ctx.ContributionStart,
sizeof(uint32_t));
Asm->OutStreamer->EmitLabel(Ctx.ContributionStart);
Asm->OutStreamer->AddComment("Header: version");
Asm->emitInt16(Version);
Asm->OutStreamer->AddComment("Header: padding");
Asm->emitInt16(Padding);
Asm->OutStreamer->AddComment("Header: compilation unit count");
Asm->emitInt32(CompUnitCount);
Asm->OutStreamer->AddComment("Header: local type unit count");
Asm->emitInt32(LocalTypeUnitCount);
Asm->OutStreamer->AddComment("Header: foreign type unit count");
Asm->emitInt32(ForeignTypeUnitCount);
Asm->OutStreamer->AddComment("Header: bucket count");
Asm->emitInt32(BucketCount);
Asm->OutStreamer->AddComment("Header: name count");
Asm->emitInt32(NameCount);
Asm->OutStreamer->AddComment("Header: abbreviation table size");
Asm->EmitLabelDifference(Ctx.AbbrevEnd, Ctx.AbbrevStart, sizeof(uint32_t));
Asm->OutStreamer->AddComment("Header: augmentation string size");
assert(AugmentationStringSize % 4 == 0);
Asm->emitInt32(AugmentationStringSize);
Asm->OutStreamer->AddComment("Header: augmentation string");
Asm->OutStreamer->EmitBytes({AugmentationString, AugmentationStringSize});
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
DenseSet<uint32_t> Dwarf5AccelTableWriter<DataT>::getUniqueTags() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
DenseSet<uint32_t> UniqueTags;
for (auto &Bucket : Contents.getBuckets()) {
for (auto *Hash : Bucket) {
for (auto *Value : Hash->Values) {
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
unsigned Tag = static_cast<const DataT *>(Value)->getDieTag();
UniqueTags.insert(Tag);
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
}
}
}
return UniqueTags;
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
SmallVector<typename Dwarf5AccelTableWriter<DataT>::AttributeEncoding, 2>
Dwarf5AccelTableWriter<DataT>::getUniformAttributes() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
SmallVector<AttributeEncoding, 2> UA;
Revert "[AccelTable] Provide abstraction for emitting DWARF5 accelerator tables." This reverts r336529 because an alternative approach turned out to be a better fit for dsymuil. llvm-svn: 336698
2018-07-10 18:18:56 +02:00
if (CompUnits.size() > 1) {
size_t LargestCUIndex = CompUnits.size() - 1;
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
dwarf::Form Form = DIEInteger::BestForm(/*IsSigned*/ false, LargestCUIndex);
UA.push_back({dwarf::DW_IDX_compile_unit, Form});
}
UA.push_back({dwarf::DW_IDX_die_offset, dwarf::DW_FORM_ref4});
return UA;
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::emitCUList() const {
Revert "[AccelTable] Provide abstraction for emitting DWARF5 accelerator tables." This reverts r336529 because an alternative approach turned out to be a better fit for dsymuil. llvm-svn: 336698
2018-07-10 18:18:56 +02:00
for (const auto &CU : enumerate(CompUnits)) {
Asm->OutStreamer->AddComment("Compilation unit " + Twine(CU.index()));
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
Asm->emitDwarfSymbolReference(CU.value());
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
}
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::emitBuckets() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
uint32_t Index = 1;
for (const auto &Bucket : enumerate(Contents.getBuckets())) {
Asm->OutStreamer->AddComment("Bucket " + Twine(Bucket.index()));
Asm->emitInt32(Bucket.value().empty() ? 0 : Index);
Index += Bucket.value().size();
}
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::emitStringOffsets() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
for (const auto &Bucket : enumerate(Contents.getBuckets())) {
for (auto *Hash : Bucket.value()) {
DwarfStringPoolEntryRef String = Hash->Name;
Asm->OutStreamer->AddComment("String in Bucket " + Twine(Bucket.index()) +
": " + String.getString());
Asm->emitDwarfStringOffset(String);
}
}
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::emitAbbrevs() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Asm->OutStreamer->EmitLabel(AbbrevStart);
for (const auto &Abbrev : Abbreviations) {
Asm->OutStreamer->AddComment("Abbrev code");
assert(Abbrev.first != 0);
Asm->EmitULEB128(Abbrev.first);
Asm->OutStreamer->AddComment(dwarf::TagString(Abbrev.first));
Asm->EmitULEB128(Abbrev.first);
for (const auto &AttrEnc : Abbrev.second) {
Asm->EmitULEB128(AttrEnc.Index, dwarf::IndexString(AttrEnc.Index).data());
Asm->EmitULEB128(AttrEnc.Form,
dwarf::FormEncodingString(AttrEnc.Form).data());
}
Asm->EmitULEB128(0, "End of abbrev");
Asm->EmitULEB128(0, "End of abbrev");
}
Asm->EmitULEB128(0, "End of abbrev list");
Asm->OutStreamer->EmitLabel(AbbrevEnd);
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
void Dwarf5AccelTableWriter<DataT>::emitEntry(const DataT &Entry) const {
auto AbbrevIt = Abbreviations.find(Entry.getDieTag());
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
assert(AbbrevIt != Abbreviations.end() &&
"Why wasn't this abbrev generated?");
Asm->EmitULEB128(AbbrevIt->first, "Abbreviation code");
for (const auto &AttrEnc : AbbrevIt->second) {
Asm->OutStreamer->AddComment(dwarf::IndexString(AttrEnc.Index));
switch (AttrEnc.Index) {
case dwarf::DW_IDX_compile_unit: {
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
DIEInteger ID(getCUIndexForEntry(Entry));
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
ID.EmitValue(Asm, AttrEnc.Form);
break;
}
case dwarf::DW_IDX_die_offset:
assert(AttrEnc.Form == dwarf::DW_FORM_ref4);
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
Asm->emitInt32(Entry.getDieOffset());
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
break;
default:
llvm_unreachable("Unexpected index attribute!");
}
}
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT> void Dwarf5AccelTableWriter<DataT>::emitData() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Asm->OutStreamer->EmitLabel(EntryPool);
for (auto &Bucket : Contents.getBuckets()) {
for (auto *Hash : Bucket) {
// Remember to emit the label for our offset.
Asm->OutStreamer->EmitLabel(Hash->Sym);
for (const auto *Value : Hash->Values)
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
emitEntry(*static_cast<const DataT *>(Value));
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Asm->OutStreamer->AddComment("End of list: " + Hash->Name.getString());
Asm->emitInt32(0);
}
}
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT>
Dwarf5AccelTableWriter<DataT>::Dwarf5AccelTableWriter(
AsmPrinter *Asm, const AccelTableBase &Contents,
ArrayRef<MCSymbol *> CompUnits,
llvm::function_ref<unsigned(const DataT &)> getCUIndexForEntry)
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
: AccelTableWriter(Asm, Contents, false),
Revert "[AccelTable] Provide abstraction for emitting DWARF5 accelerator tables." This reverts r336529 because an alternative approach turned out to be a better fit for dsymuil. llvm-svn: 336698
2018-07-10 18:18:56 +02:00
Header(CompUnits.size(), Contents.getBucketCount(),
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Contents.getUniqueNameCount()),
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
CompUnits(CompUnits), getCUIndexForEntry(std::move(getCUIndexForEntry)) {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
DenseSet<uint32_t> UniqueTags = getUniqueTags();
SmallVector<AttributeEncoding, 2> UniformAttributes = getUniformAttributes();
Abbreviations.reserve(UniqueTags.size());
for (uint32_t Tag : UniqueTags)
Abbreviations.try_emplace(Tag, UniformAttributes);
}
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
template <typename DataT> void Dwarf5AccelTableWriter<DataT>::emit() const {
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Header.emit(*this);
emitCUList();
emitBuckets();
emitHashes();
emitStringOffsets();
emitOffsets(EntryPool);
emitAbbrevs();
emitData();
Asm->OutStreamer->EmitValueToAlignment(4, 0);
Asm->OutStreamer->EmitLabel(ContributionEnd);
}
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
void llvm::emitAppleAccelTableImpl(AsmPrinter *Asm, AccelTableBase &Contents,
StringRef Prefix, const MCSymbol *SecBegin,
ArrayRef<AppleAccelTableData::Atom> Atoms) {
Contents.finalize(Asm, Prefix);
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
AppleAccelTableWriter(Asm, Contents, Atoms, SecBegin).emit();
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
}
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
void llvm::emitDWARF5AccelTable(
AsmPrinter *Asm, AccelTable<DWARF5AccelTableData> &Contents,
const DwarfDebug &DD, ArrayRef<std::unique_ptr<DwarfCompileUnit>> CUs) {
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
std::vector<MCSymbol *> CompUnits;
for (const auto &CU : enumerate(CUs)) {
assert(CU.index() == CU.value()->getUniqueID());
const DwarfCompileUnit *MainCU =
DD.useSplitDwarf() ? CU.value()->getSkeleton() : CU.value().get();
CompUnits.push_back(MainCU->getLabelBegin());
}
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
Contents.finalize(Asm, "names");
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
Dwarf5AccelTableWriter<DWARF5AccelTableData>(
Asm, Contents, CompUnits,
[&DD](const DWARF5AccelTableData &Entry) {
const DIE *CUDie = Entry.getDie().getUnitDie();
return DD.lookupCU(CUDie)->getUniqueID();
})
.emit();
}
void llvm::emitDWARF5AccelTable(
AsmPrinter *Asm, AccelTable<DWARF5AccelTableStaticData> &Contents,
ArrayRef<MCSymbol *> CUs,
llvm::function_ref<unsigned(const DWARF5AccelTableStaticData &)>
getCUIndexForEntry) {
Contents.finalize(Asm, "names");
Dwarf5AccelTableWriter<DWARF5AccelTableStaticData>(Asm, Contents, CUs,
getCUIndexForEntry)
.emit();
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
}
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
void AppleAccelTableOffsetData::emit(AsmPrinter *Asm) const {
DwarfDebug: Reduce duplication in addAccel*** methods Summary: Each of the four methods had a dozen lines and was doing almost exactly the same thing: get the appropriate accelerator table kind and insert an entry into it. I move this common logic to a helper function and make these methods delegate to it. This came up in the context of D49493, where I've needed to make adding a string to a string pool slightly more complicated, and it seemed to make sense to do it in one place instead of five. To make this work I've needed to unify the interface of the AccelTable data types, as some used to store DIE& and others DIE*. I chose to unify to a reference as that's what the caller uses. This technically isn't NFC, because it changes the StringPool used for apple tables in the DWO case (now it uses the main file like DWARF v5 instead of the DWO file). However, that shouldn't matter, as DWO is not a thing on apple targets (clang frontend simply ignores -gsplit-dwarf). Reviewers: JDevlieghere, aprantl, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49542 llvm-svn: 337562
2018-07-20 17:24:13 +02:00
Asm->emitInt32(Die.getDebugSectionOffset());
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
}
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
[NFC] Refactor Apple Accelerator Tables This patch refactors the way data is stored in the accelerator table and makes them truly generic. There have been several attempts to do this in the past: - D8215 & D8216: Using a union and partial hardcoding. - D11805: Using inheritance. - D42246: Using a callback. In the end I didn't like either of them, because for some reason or another parts of it felt hacky or decreased runtime performance. I didn't want to completely rewrite them as I was hoping that we could reuse parts for the successor in the DWARF standard. However, it seems less and less likely that there will be a lot of opportunities for sharing code and/or an interface. Originally I choose to template the whole class, because it introduces no performance overhead compared to the original implementation. We ended up settling on a hybrid between a templated method and a virtual call to emit the data. The motivation is that we don't want to increase code size for a feature that should soon be superseded by the DWARFv5 accelerator tables. While the code will continue to be used for compatibility, it won't be on the hot path. Furthermore this does not regress performance compared to Apple's internal implementation that already uses virtual calls for this. A quick summary for why these changes are necessary: dsymutil likes to reuse the current implementation of the Apple accelerator tables. However, LLDB expects a slightly different interface than what is currently emitted. Additionally, in dsymutil we only have offsets and no actual DIEs. Although the patch suggests a lot of code has changed, this change is pretty straightforward: - We created an abstract class `AppleAccelTableData` to serve as an interface for the different data classes. - We created two implementations of this class, one for type tables and one for everything else. There will be a third one for dsymutil that takes just the offset. - We use the supplied class to deduct the atoms for the header which makes the structure of the table fully self contained, although not enforced by the interface as was the case for the fully templated approach. - We renamed the prefix from DWARF- to Apple- to make space for the future implementation of .debug_names. This change is NFC and relies on the existing tests. Differential revision: https://reviews.llvm.org/D42334 llvm-svn: 323653
2018-01-29 15:52:34 +01:00
void AppleAccelTableTypeData::emit(AsmPrinter *Asm) const {
DwarfDebug: Reduce duplication in addAccel*** methods Summary: Each of the four methods had a dozen lines and was doing almost exactly the same thing: get the appropriate accelerator table kind and insert an entry into it. I move this common logic to a helper function and make these methods delegate to it. This came up in the context of D49493, where I've needed to make adding a string to a string pool slightly more complicated, and it seemed to make sense to do it in one place instead of five. To make this work I've needed to unify the interface of the AccelTable data types, as some used to store DIE& and others DIE*. I chose to unify to a reference as that's what the caller uses. This technically isn't NFC, because it changes the StringPool used for apple tables in the DWO case (now it uses the main file like DWARF v5 instead of the DWO file). However, that shouldn't matter, as DWO is not a thing on apple targets (clang frontend simply ignores -gsplit-dwarf). Reviewers: JDevlieghere, aprantl, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49542 llvm-svn: 337562
2018-07-20 17:24:13 +02:00
Asm->emitInt32(Die.getDebugSectionOffset());
Asm->emitInt16(Die.getTag());
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt8(0);
Add a new dwarf accelerator table prototype with the goal of replacing the pubnames and pubtypes tables. LLDB can currently use this format and a full spec is forthcoming and submission for standardization is planned. A basic summary: The dwarf accelerator tables are an indirect hash table optimized for null lookup rather than access to known data. They are output into an on-disk format that looks like this: .-------------. | HEADER | |-------------| | BUCKETS | |-------------| | HASHES | |-------------| | OFFSETS | |-------------| | DATA | `-------------' where the header contains a magic number, version, type of hash function, the number of buckets, total number of hashes, and room for a special struct of data and the length of that struct. The buckets contain an index (e.g. 6) into the hashes array. The hashes section contains all of the 32-bit hash values in contiguous memory, and the offsets contain the offset into the data area for the particular hash. For a lookup example, we could hash a function name and take it modulo the number of buckets giving us our bucket. From there we take the bucket value as an index into the hashes table and look at each successive hash as long as the hash value is still the same modulo result (bucket value) as earlier. If we have a match we look at that same entry in the offsets table and grab the offset in the data for our final match. llvm-svn: 143921
2011-11-07 10:18:42 +01:00
}
[dsymutil] Generate Apple accelerator tables This patch adds support for generating accelerator tables in dsymutil. This feature was already present in our internal repository but not yet upstreamed because it requires changes to the Apple accelerator table implementation. Differential revision: https://reviews.llvm.org/D42501 llvm-svn: 323655
2018-01-29 15:52:50 +01:00
void AppleAccelTableStaticOffsetData::emit(AsmPrinter *Asm) const {
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(Offset);
[dsymutil] Generate Apple accelerator tables This patch adds support for generating accelerator tables in dsymutil. This feature was already present in our internal repository but not yet upstreamed because it requires changes to the Apple accelerator table implementation. Differential revision: https://reviews.llvm.org/D42501 llvm-svn: 323655
2018-01-29 15:52:50 +01:00
}
void AppleAccelTableStaticTypeData::emit(AsmPrinter *Asm) const {
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(Offset);
Asm->emitInt16(Tag);
Asm->emitInt8(ObjCClassIsImplementation ? dwarf::DW_FLAG_type_implementation
[dsymutil] Generate Apple accelerator tables This patch adds support for generating accelerator tables in dsymutil. This feature was already present in our internal repository but not yet upstreamed because it requires changes to the Apple accelerator table implementation. Differential revision: https://reviews.llvm.org/D42501 llvm-svn: 323655
2018-01-29 15:52:50 +01:00
: 0);
Style update. NFC. Rename 3 functions to start with lowercase letters. Don't repeat the name in the comments. llvm-svn: 328848
2018-03-30 01:32:54 +02:00
Asm->emitInt32(QualifiedNameHash);
[dsymutil] Generate Apple accelerator tables This patch adds support for generating accelerator tables in dsymutil. This feature was already present in our internal repository but not yet upstreamed because it requires changes to the Apple accelerator table implementation. Differential revision: https://reviews.llvm.org/D42501 llvm-svn: 323655
2018-01-29 15:52:50 +01:00
}
[AccelTable] Workaround for MSVC bug Microsoft Visual Studio rejects the static constexpr static list of atoms even though it's valid C++. This provides a workaround to unbreak the bots. llvm-svn: 323667
2018-01-29 18:28:51 +01:00
#ifndef _MSC_VER
// The lines below are rejected by older versions (TBD) of MSVC.
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
constexpr AppleAccelTableData::Atom AppleAccelTableTypeData::Atoms[];
constexpr AppleAccelTableData::Atom AppleAccelTableOffsetData::Atoms[];
constexpr AppleAccelTableData::Atom AppleAccelTableStaticOffsetData::Atoms[];
constexpr AppleAccelTableData::Atom AppleAccelTableStaticTypeData::Atoms[];
[AccelTable] Workaround for MSVC bug Microsoft Visual Studio rejects the static constexpr static list of atoms even though it's valid C++. This provides a workaround to unbreak the bots. llvm-svn: 323667
2018-01-29 18:28:51 +01:00
#else
// FIXME: Erase this path once the minimum MSCV version has been bumped.
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
const SmallVector<AppleAccelTableData::Atom, 4>
AppleAccelTableOffsetData::Atoms = {
Atom(dwarf::DW_ATOM_die_offset, dwarf::DW_FORM_data4)};
const SmallVector<AppleAccelTableData::Atom, 4> AppleAccelTableTypeData::Atoms =
{Atom(dwarf::DW_ATOM_die_offset, dwarf::DW_FORM_data4),
Atom(dwarf::DW_ATOM_die_tag, dwarf::DW_FORM_data2),
Atom(dwarf::DW_ATOM_type_flags, dwarf::DW_FORM_data1)};
const SmallVector<AppleAccelTableData::Atom, 4>
AppleAccelTableStaticOffsetData::Atoms = {
Atom(dwarf::DW_ATOM_die_offset, dwarf::DW_FORM_data4)};
const SmallVector<AppleAccelTableData::Atom, 4>
[AccelTable] Workaround for MSVC bug Microsoft Visual Studio rejects the static constexpr static list of atoms even though it's valid C++. This provides a workaround to unbreak the bots. llvm-svn: 323667
2018-01-29 18:28:51 +01:00
AppleAccelTableStaticTypeData::Atoms = {
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
Atom(dwarf::DW_ATOM_die_offset, dwarf::DW_FORM_data4),
Atom(dwarf::DW_ATOM_die_tag, dwarf::DW_FORM_data2),
Atom(5, dwarf::DW_FORM_data1), Atom(6, dwarf::DW_FORM_data4)};
[AccelTable] Workaround for MSVC bug Microsoft Visual Studio rejects the static constexpr static list of atoms even though it's valid C++. This provides a workaround to unbreak the bots. llvm-svn: 323667
2018-01-29 18:28:51 +01:00
#endif
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
#ifndef NDEBUG
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::Header::print(raw_ostream &OS) const {
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
OS << "Magic: " << format("0x%x", Magic) << "\n"
<< "Version: " << Version << "\n"
<< "Hash Function: " << HashFunction << "\n"
<< "Bucket Count: " << BucketCount << "\n"
<< "Header Data Length: " << HeaderDataLength << "\n";
}
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
void AppleAccelTableData::Atom::print(raw_ostream &OS) const {
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
OS << "Type: " << dwarf::AtomTypeString(Type) << "\n"
<< "Form: " << dwarf::FormEncodingString(Form) << "\n";
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::HeaderData::print(raw_ostream &OS) const {
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
OS << "DIE Offset Base: " << DieOffsetBase << "\n";
for (auto Atom : Atoms)
Atom.print(OS);
}
[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC) Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested in D49031. llvm-svn: 336525
2018-07-09 10:47:38 +02:00
void AppleAccelTableWriter::print(raw_ostream &OS) const {
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
Header.print(OS);
HeaderData.print(OS);
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
Contents.print(OS);
SecBegin->print(OS, nullptr);
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
}
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
void AccelTableBase::HashData::print(raw_ostream &OS) const {
[CodeGen] Optimize AccelTable Summary: The class contained arrays of two structures (DataArray and HashData). These structures were in 1:1 correspondence, and one of them contained pointers to the other (and *both* contained a "Name" field). By merging these two structures into one, we can save a bit of space without negatively impacting much of anything. Reviewers: JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43073 llvm-svn: 324724
2018-02-09 11:06:56 +01:00
OS << "Name: " << Name.getString() << "\n";
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
OS << " Hash Value: " << format("0x%x", HashValue) << "\n";
OS << " Symbol: ";
if (Sym)
OS << *Sym;
else
OS << "<none>";
OS << "\n";
[CodeGen] Optimize AccelTable Summary: The class contained arrays of two structures (DataArray and HashData). These structures were in 1:1 correspondence, and one of them contained pointers to the other (and *both* contained a "Name" field). By merging these two structures into one, we can save a bit of space without negatively impacting much of anything. Reviewers: JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43073 llvm-svn: 324724
2018-02-09 11:06:56 +01:00
for (auto *Value : Values)
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
Value->print(OS);
}
[CodeGen] Refactor AppleAccelTable Summary: This commit separates the abstract accelerator table data structure from the code for writing out an on-disk representation of a specific accelerator table format. The idea is that former (now called AccelTable<T>) can be reused for the DWARF v5 accelerator tables as-is, without any further customizations. Some bits of the emission code (now living in the EmissionContext class) can be reused for DWARF v5 as well, but the subtle differences in the layout of various subtables mean the sharing is not always possible. (Also, the individual emit*** functions are fairly simple so there's a tradeoff between making a bigger general-purpose function, and two smaller targeted functions.) Another advantage of this setup is that more of the serialization logic can be hidden in the .cpp file -- I have moved declarations of the header and all the emission functions there. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D43285 llvm-svn: 325516
2018-02-19 17:12:20 +01:00
void AccelTableBase::print(raw_ostream &OS) const {
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
// Print Content.
OS << "Entries: \n";
for (const auto &Entry : Entries) {
OS << "Name: " << Entry.first() << "\n";
for (auto *V : Entry.second.Values)
V->print(OS);
}
OS << "Buckets and Hashes: \n";
for (auto &Bucket : Buckets)
for (auto &Hash : Bucket)
Hash->print(OS);
OS << "Data: \n";
[CodeGen] Optimize AccelTable Summary: The class contained arrays of two structures (DataArray and HashData). These structures were in 1:1 correspondence, and one of them contained pointers to the other (and *both* contained a "Name" field). By merging these two structures into one, we can save a bit of space without negatively impacting much of anything. Reviewers: JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43073 llvm-svn: 324724
2018-02-09 11:06:56 +01:00
for (auto &E : Entries)
E.second.print(OS);
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
}
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
void DWARF5AccelTableData::print(raw_ostream &OS) const {
[AccelTable] Provide DWARF5AccelTableStaticData for dsymutil. For dsymutil we want to store offsets in the accelerator table entries rather than DIE pointers. In addition, we need a way to communicate which CU a DIE belongs to. This patch provides support for both of these issues. Differential revision: https://reviews.llvm.org/D49102 llvm-svn: 337158
2018-07-16 12:52:27 +02:00
OS << " Offset: " << getDieOffset() << "\n";
OS << " Tag: " << dwarf::TagString(getDieTag()) << "\n";
}
void DWARF5AccelTableStaticData::print(raw_ostream &OS) const {
OS << " Offset: " << getDieOffset() << "\n";
OS << " Tag: " << dwarf::TagString(getDieTag()) << "\n";
Re-commit r329179 after fixing build&test issues - MSVC was not OK with a static_assert referencing a non-static member variable, even though it was just in a sizeof(expression). I move the assert into the emit function, where it is probably more useful. - Tests were failing in builds which did not have the X86 target configured. Since this functionality is not target-specific, I have removed the target specifiers from the .ll files. llvm-svn: 329201
2018-04-04 16:42:14 +02:00
}
[AccelTable] Move print methods to implementation. NFC This patch moves the implementation of the print methods from the header to the cpp file. llvm-svn: 323757
2018-01-30 14:36:30 +01:00
void AppleAccelTableOffsetData::print(raw_ostream &OS) const {
OS << " Offset: " << Die->getOffset() << "\n";
}
void AppleAccelTableTypeData::print(raw_ostream &OS) const {
OS << " Offset: " << Die->getOffset() << "\n";
OS << " Tag: " << dwarf::TagString(Die->getTag()) << "\n";
}
void AppleAccelTableStaticOffsetData::print(raw_ostream &OS) const {
OS << " Static Offset: " << Offset << "\n";
}
void AppleAccelTableStaticTypeData::print(raw_ostream &OS) const {
OS << " Static Offset: " << Offset << "\n";
OS << " QualifiedNameHash: " << format("%x\n", QualifiedNameHash) << "\n";
OS << " Tag: " << dwarf::TagString(Tag) << "\n";
OS << " ObjCClassIsImplementation: "
<< (ObjCClassIsImplementation ? "true" : "false");
OS << "\n";
}
#endif
Reference in New Issue Copy Permalink