History log of /llvm-project/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp (Results 1 – 25 of 68)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# 2fccd5c5 03-Nov-2024 Kazu Hirata <kazu@google.com>

[AsmPrinter] Remove unused includes (NFC) (#114698)

Identified with misc-include-cleaner.


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2
# 8d1b17b6 04-Aug-2024 Kazu Hirata <kazu@google.com>

[CodeGen] Construct SmallVector with ArrayRef (NFC) (#101841)


Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8
# 7c6d0d26 15-Jun-2024 Kazu Hirata <kazu@google.com>

[llvm] Use llvm::unique (NFC) (#95628)


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4
# d3016aa8 09-Apr-2024 Fangrui Song <i@maskray.me>

[DWARF] Refactor .debug_names bucket count computation (#88087)

`getDebugNamesBucketAndHashCount` lures users to provide an array to
compute the bucket count using an O(n log n) sort. This is ineff

[DWARF] Refactor .debug_names bucket count computation (#88087)

`getDebugNamesBucketAndHashCount` lures users to provide an array to
compute the bucket count using an O(n log n) sort. This is inefficient
as hash table based uniquifying is faster.

The performance issue matters less for Clang as the number of names is
relatively small. For `ld.lld --debug-names`, I plan to compute the
unique hash count as a side product of parallel entry pool computation,
and I just need a function to suggest a bucket count.

show more ...


Revision tags: llvmorg-18.1.3, llvmorg-18.1.2
# 390f2870 13-Mar-2024 mahesh-attarde <145317060+mahesh-attarde@users.noreply.github.com>

[CodeGen][Tablegen] Fix uninitialized var and shift overflow. (#84896)

Fix uninitialized var and shift overflow.


Revision tags: llvmorg-18.1.1
# 7b0b64a7 01-Mar-2024 Fangrui Song <i@maskray.me>

[DWARF] Use std::tie after #83047. NFC

The code suggestion was neglected when the patch landed.


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4
# f0663772 27-Feb-2024 cmtice <cmtice@google.com>

[LLVM][DWARF] Make dwarf::getDebugNamesBucketCount return a pair. (#83047)

llvm::dwarf::getDebugNamesBucketCount directly returns the bucket count,
via return statement, but it also returns the has

[LLVM][DWARF] Make dwarf::getDebugNamesBucketCount return a pair. (#83047)

llvm::dwarf::getDebugNamesBucketCount directly returns the bucket count,
via return statement, but it also returns the hash count via a
parameter. This changes the function to return them both as a std::pair,
in the return statement. It also changes the name of the function to
make it clear it returns both values.

show more ...


# 453b1a2f 21-Feb-2024 cmtice <cmtice@google.com>

[LLVM][DWARF] Refactor code for generating DWARF V5 .debug_names (#82394)

[LLVM][DWARF] Refactor code for generating DWARF v5 .debug_names

Refactor the code that uniques the entries and computes

[LLVM][DWARF] Refactor code for generating DWARF V5 .debug_names (#82394)

[LLVM][DWARF] Refactor code for generating DWARF v5 .debug_names

Refactor the code that uniques the entries and computes the bucket count
for the DWARF V5 .debug_names accelerator table.

show more ...


Revision tags: llvmorg-18.1.0-rc3
# f905877f 15-Feb-2024 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM][DWARF] Fix for memory leak (#81828)

This is followup to https://github.com/llvm/llvm-project/pull/8120.
Missed a destuctor.


# a78d13d0 14-Feb-2024 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM][DWARF] Change .debug_names abbrev to be an index (#81200)

Based on the discussion in
https://github.com/llvm/llvm-project/pull/80229
changed implementation to align with how .debug_abbrev i

[LLVM][DWARF] Change .debug_names abbrev to be an index (#81200)

Based on the discussion in
https://github.com/llvm/llvm-project/pull/80229
changed implementation to align with how .debug_abbrev is handled. So
that
.debug_names abbrev tag is a monotonically increasing index. This allows
for
tools like LLDB to access it in constant time using array like data
structure.

clang-19 debug build
before change

[41] .debug_names PROGBITS 0000000000000000 8f9e0350 137fdbe0 00 0 0 4
after change
[41] .debug_names PROGBITS 0000000000000000 8f9e0350 125bfdec 00 0 0 4

Reduction ~19.1MB

show more ...


Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# b6677835 19-Jan-2024 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

[AsmPrinter][DebugNames] Implement DW_IDX_parent entries (#77457)

This implements the ideas discussed in [1].

To summarize, this commit changes AsmPrinter so that it outputs
DW_IDX_parent inform

[AsmPrinter][DebugNames] Implement DW_IDX_parent entries (#77457)

This implements the ideas discussed in [1].

To summarize, this commit changes AsmPrinter so that it outputs
DW_IDX_parent information for debug_name entries. It will enable
debuggers to speed up queries for fully qualified types (based on a
DWARFDeclContext) significantly, as debuggers will no longer need to
parse the entire CU in order to inspect the parent chain of a DIE.
Instead, a debugger can simply take the parent DIE offset from the
accelerator table and peek at its name in the debug_info/debug_str
sections.

The implementation uses two types of DW_FORM for the DW_IDX_parent
attribute:

1. DW_FORM_ref4, which points to the accelerator table entry for the
parent.
2. DW_FORM_flag_present, when the entry has a parent that is not in the
table (that is, the parent doesn't have a name, or isn't allowed to be
in the table as per the DWARF spec). This is space-efficient, since it
takes 0 bytes.

The implementation works by:

1. Changing how abbreviations are encoded (so that they encode which
form, if
any, was used to encode IDX_Parent)
2. Creating an MCLabel per accelerator table entry, so that they may be
referred by IDX_parent references.


When all patches related to this are merged, we are able to show that
evaluating an expression such as:

```
lldb --batch -o 'b CodeGenFunction::GenerateCode' -o run -o 'expr Fn' -- \
clang++ -c -g test.cpp -o /dev/null
```

is far faster: from ~5000 ms to ~1500ms.

Building llvm-project + clang with and without this patch, and looking
at its impact on object file size:

```
ls -la $(find build_stage2_Debug_idx_parent_assert_dwarf5 -name \*.cpp.o) | awk '{s+=$5} END {printf "%\047d\n", s}'
11,507,327,592

-la $(find build_stage2_Debug_no_idx_parent_assert_dwarf5 -name \*.cpp.o) | awk '{s+=$5} END {printf "%\047d\n", s}'
11,436,446,616
```

That is, an increase of 0.62% in total object file size.

Looking only at debug_names:

```
$stage1_build/bin/llvm-objdump --section-headers $(find build_stage2_Debug_idx_parent_assert_dwarf5 -name \*.cpp.o) | grep __debug_names | awk '{s+="0x"$3} END {printf "%\047d\n", s}'
440,772,348

$stage1_build/bin/llvm-objdump --section-headers $(find build_stage2_Debug_no_idx_parent_assert_dwarf5 -name \*.cpp.o) | grep __debug_names | awk '{s+="0x"$3} END {printf "%\047d\n", s}'
369,867,920
```

That is an increase of 19%.

DWARF Linkers need to be changed in order to support this. This commit
already brings support to "base" linker, but it does not attempt to
modify the parallel linker. Accelerator entries refer to the
corresponding DIE offset, and this patch also requires the parent DIE
offset -- it's not clear how the parallel linker can access this. It may
be obvious to someone familiar with it, but it would be nice to get help
from its authors.

[1]:
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/

show more ...


# e72c7167 08-Jan-2024 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

[AccelTable][nfc] Add helper function to cast AccelTableData (#77100)

Specializations of AccelTableBase are always interested in accessing the
derived versions of their data classes (e.g. DWARF5Acc

[AccelTable][nfc] Add helper function to cast AccelTableData (#77100)

Specializations of AccelTableBase are always interested in accessing the
derived versions of their data classes (e.g. DWARF5AccelTableData). They
do so by sprinkling `static_casts` all over the code.

This commit adds a helper function to simplify this process, reducinng
the number of casts that have to be made in the middle of code, making
it easier to read.

show more ...


# 2b88bd11 05-Jan-2024 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

[AsmPrinter][Dwarf5][nfc] Remove template from AccelTable class (#76296)

This template is no longer used.


# 058e5274 21-Dec-2023 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

[AccelTable][NFC] Fix typos and duplicated code (#76155)

Renaming a member variable from "Endoding" to "Encoding".

Also replace inlined code for "isNormalized" with a call to the
function, so th

[AccelTable][NFC] Fix typos and duplicated code (#76155)

Renaming a member variable from "Endoding" to "Encoding".

Also replace inlined code for "isNormalized" with a call to the
function, so that if the definition of normalization ever changes, we
only need to change the one place.

show more ...


# e8f3ccd2 04-Dec-2023 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM][DWARF] Add support for .debug_names with split dwarf (#73872)

Enables Type Units with DWARF5 accelerator tables for split dwarf. It is
still
under discussion what is the best way to impleme

[LLVM][DWARF] Add support for .debug_names with split dwarf (#73872)

Enables Type Units with DWARF5 accelerator tables for split dwarf. It is
still
under discussion what is the best way to implement support for
de-duplication in
DWP. This will be in follow up PR.

show more ...


Revision tags: llvmorg-17.0.6
# b00e2f2a 18-Nov-2023 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM][DWARF] Add support for monolithic types in .debug_names (#70515)

Enable Type Units with DWARF5 accelerator tables for monolithic DWARF.
Implementation relies on linker to tombstone offset in

[LLVM][DWARF] Add support for monolithic types in .debug_names (#70515)

Enable Type Units with DWARF5 accelerator tables for monolithic DWARF.
Implementation relies on linker to tombstone offset in LocalTU list to
-1 when
it deduplciates type units using COMDAT.

show more ...


Revision tags: llvmorg-17.0.5, llvmorg-17.0.4
# da27c25c 25-Oct-2023 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM[NFC] Refactor to allow debug_names entries to conatain DIE offset (#69399)

This is pre-cursor patch to enabling type units with DWARF5 acceleration
tables.
With this change it allows for ent

[LLVM[NFC] Refactor to allow debug_names entries to conatain DIE offset (#69399)

This is pre-cursor patch to enabling type units with DWARF5 acceleration
tables.
With this change it allows for entries to contain offsets directly, this
way type
units do not need to be preserved until .debug_names is written out.

show more ...


Revision tags: llvmorg-17.0.3
# 6e8013a1 14-Oct-2023 Kazu Hirata <kazu@google.com>

[llvm] Stop including llvm/ADT/StringMap.h (NFC)

These source files do not use StringMap.


# f320065a 05-Oct-2023 Nico Weber <thakis@chromium.org>

Revert "[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)"

This reverts commit 9bbd2bf654634cd95dd0be7948ec8402c3c76e1e.

Accidental commit: https://github.com/llvm/llvm-projec

Revert "[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)"

This reverts commit 9bbd2bf654634cd95dd0be7948ec8402c3c76e1e.

Accidental commit: https://github.com/llvm/llvm-project/pull/68131#issuecomment-1749430207

show more ...


# 9bbd2bf6 05-Oct-2023 Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com>

[LLVM][DWARF] Add support for monolithic types in .debug_names (#68131)

Added support for Type Units in monolithic DWARF in .debug_names.


Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# 08136d82 04-Jul-2023 Alexey Lapshin <a.v.lapshin@mail.ru>

[DWARFLinkerParallel] Add support of accelerator tables to DWARFLinkerParallel.

This patch is extracted from D96035, it adds support for the accelerator
tables to the DWARFLinkerParallel functionali

[DWARFLinkerParallel] Add support of accelerator tables to DWARFLinkerParallel.

This patch is extracted from D96035, it adds support for the accelerator
tables to the DWARFLinkerParallel functionality.

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

show more ...


# 60a2b991 20-Jul-2023 Fangrui Song <i@maskray.me>

AccelTable: Use MapVector to stabilize iteration order

Entries of the same DJB hash are in the hash lookup table/name table are
ordered by the iteration order of `Entries` (a StringMap). Change
`Ent

AccelTable: Use MapVector to stabilize iteration order

Entries of the same DJB hash are in the hash lookup table/name table are
ordered by the iteration order of `Entries` (a StringMap). Change
`Entries` to a MapVector to stabilize the order and simplify future
changes like D142862 that change the StringMap hash function.

show more ...


# fc60bf2d 14-Jun-2023 Jonas Devlieghere <jonas@devlieghere.com>

[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms

On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWA

[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms

On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWARF 4
and earlier. For DWARF 5 we should generate .debug_names, but instead we
get no accelerator tables at all.

In the backend we are correctly determining that we should be emitting
.debug_names instead of .apple_names. However, when we get to the point
of emitting the section, if the CU debug name table kind is not
"default", the accelerator table emission is skipped.

This patch sets the DebugNameTableKind to Apple in the frontend when
target an Apple target. That way we know that the CU was compiled with
the intent of emitting accelerator tables. For DWARF 4 and earlier, that
means Apple accelerator tables. For DWARF 5 and later, that means .debug
names.

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

show more ...


# 04c0161c 14-Jun-2023 Jonas Devlieghere <jonas@devlieghere.com>

Revert "[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms"

This reverts commit e0d57295bf6a3c04f2901d9c70f529d570f48b65 because the
accel-tables-apple.ll test is failing on a f

Revert "[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms"

This reverts commit e0d57295bf6a3c04f2901d9c70f529d570f48b65 because the
accel-tables-apple.ll test is failing on a few buildbots.

show more ...


# e0d57295 14-Jun-2023 Jonas Devlieghere <jonas@devlieghere.com>

[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms

On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWA

[DebugInfo] Always emit `.debug_names` with DWARF 5 for Apple platforms

On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWARF 4
and earlier. For DWARF 5 we should generate .debug_names, but instead we
get no accelerator tables at all.

In the backend we are correctly determining that we should be emitting
.debug_names instead of .apple_names. However, when we get to the point
of emitting the section, if the CU debug name table kind is not
"default", the accelerator table emission is skipped.

This patch sets the DebugNameTableKind to Apple in the frontend when
target an Apple target. That way we know that the CU was compiled with
the intent of emitting accelerator tables. For DWARF 4 and earlier, that
means Apple accelerator tables. For DWARF 5 and later, that means .debug
names.

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

show more ...


123