[CodeGen] Fix inconsistent declaration parameter name

llvm-svn: 337200

[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 communica

[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

show more ...

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

[AccelTable] Provide abstraction for emitting DWARF5 accelerator tables.

When emitting the DWARF accelerator tables from dsymutil, we don't have
a DwarfDebug instance and we use a custom class to re

[AccelTable] Provide abstraction for emitting DWARF5 accelerator tables.

When emitting the DWARF accelerator tables from dsymutil, we don't have
a DwarfDebug instance and we use a custom class to represent Dwarf
compile units. This patch adds an interface AccelTableWriterInfo to
abstract these from the Dwarf5AccelTableWriter, so we can have a custom
implementation for this in dsymutil.

Differential revision: https://reviews.llvm.org/D49031

llvm-svn: 336529

show more ...

[AccelTable] Dwarf5AccelTableEmitter -> Writer (NFC)

Renames Dwarf5AccelTableEmitter to Dwarf5AccelTableWriter as suggested
in D49031.

llvm-svn: 336525

[CodeGen/Dwarf] Make debug_names compatible with split-dwarf

Summary:
Previously we crashed for the combination of the two features because we
tried to reference the dwo CU from the main object file

[CodeGen/Dwarf] Make debug_names compatible with split-dwarf

Summary:
Previously we crashed for the combination of the two features because we
tried to reference the dwo CU from the main object file. The fix
consists of two items:
- reference the skeleton CU from the name index (the consumer is
expected to use the skeleton CU to find the real data).
- use the main object file string pool for the strings in the index

Reviewers: JDevlieghere, aprantl, dblaikie

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D45566

llvm-svn: 330249

show more ...

[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 emp

[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

show more ...

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
asse

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

show more ...

Revert r329179 (and follow-up unsuccessful fix attempts 329184, 329186); it doesn't build.

llvm-svn: 329190

[CodeGen] Generate DWARF v5 Accelerator Tables

Summary:
This patch adds a DwarfAccelTableEmitter class, which generates an
accelerator table, as specified in DWARF v5 standard. At the moment it
only

[CodeGen] Generate DWARF v5 Accelerator Tables

Summary:
This patch adds a DwarfAccelTableEmitter class, which generates an
accelerator table, as specified in DWARF v5 standard. At the moment it
only generates a DIE offset column and (if we are indexing more than one
compile unit) a CU column.

Indexing type units is not currently supported, as we don't even have
the ability to generate DWARF v5-compatible compile units.

The implementation is not data-source agnostic like the one generating
apple tables. This was not necessary as we currently only have one user
of this code, and without a second user it was not obvious to me how to
best abstract this. (The difference between these tables and the apple
ones is that they need a lot more metadata about the debug info they are
indexing).

The generation is triggered by the --accel-tables argument, which
supersedes the --dwarf-accel-tables arg -- the latter was a simple
on-off switch, but not we can choose between two kinds of accelerator
tables we can generate.

This is tested by parsing the generated tables with llvm-dwarfdump and
the DWARFVerifier, and I've also checked that GNU readelf is able to
make sense of the tables.

Differential Revision: https://reviews.llvm.org/D43286

llvm-svn: 329179

show more ...

Style update. NFC.

Rename 3 functions to start with lowercase letters. Don't repeat the
name in the comments.

llvm-svn: 328848

[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 tabl

[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

show more ...

[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 o

[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

show more ...

[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

[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:

[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

show more ...

[AccelTable] Try making MSVC happy

MSVC complains that the constexpr "expression did not evaluate to a
constant". Trying to make it happy by adding a `const` specifier as
suggested in https://stacko

[AccelTable] Try making MSVC happy

MSVC complains that the constexpr "expression did not evaluate to a
constant". Trying to make it happy by adding a `const` specifier as
suggested in https://stackoverflow.com/questions/37574343.

llvm-svn: 323659

show more ...

[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

[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

show more ...

[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 implementat

[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

show more ...