llvm-project.git/llvm/lib/DebugInfo/PDB/Native/DbiModuleDescriptorBuilder.cpp, branch main

Cleanup llvm/DebugInfo/PDB headers

2022-02-23T09:31:34+00:00

accumulated preprocessed size:
before: 1065515095
after: 1065629059

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120195

[llvm] Use = default (NFC)

2022-02-07T06:18:35+00:00

Re-land "[PDB] Defer relocating .debug$S until commit time and parallelize it"

2021-03-10T23:14:09+00:00

This reverts commit bacf9cf2c5cdec3567580e5030c4c82f42b3d745 and
reinstates commit 1a9bd5b81328adf0dd5a8b4f3ad5949463e66da3.

Reverting this commit did not appear to make the problem go away, so we
can go ahead and reland it.

Revert "[PDB] Defer relocating .debug$S until commit time and parallelize it"

2021-01-28T21:17:27+00:00

This reverts commit 1a9bd5b81328adf0dd5a8b4f3ad5949463e66da3.

I suspect that this patch may have caused https://crbug.com/1171438.

Reland "[PDB] Defer relocating .debug$S until commit time and parallelize it"

2021-01-20T19:53:43+00:00

This reverts commit 5b7aef6eb4b2930971029b984cb2360f7682e5a5 and relands
6529d7c5a45b1b9588e512013b02f891d71bc134.

The ASan error was debugged and determined to be the fault of an invalid
object file input in our test suite, which was fixed by my last change.
LLD's project policy is that it assumes input objects are valid, so I
have added a comment about this assumption to the relocation bounds
check.

Revert "[PDB] Defer relocating .debug$S until commit time and parallelize it"

2021-01-19T19:45:48+00:00

This reverts commit 6529d7c5a45b1b9588e512013b02f891d71bc134.

Reason: Broke the ASan buildbots.
http://lab.llvm.org:8011/#/builders/99/builds/1567

[PDB] Defer relocating .debug$S until commit time and parallelize it

2021-01-13T01:46:29+00:00

This is a pretty classic optimization. Instead of processing symbol
records and copying them to temporary storage, do a first pass to
measure how large the module symbol stream will be, and then copy the
data into place in the PDB file. This requires defering relocation until
much later, which accounts for most of the complexity in this patch.

This patch avoids copying the contents of all live .debug$S sections
into heap memory, which is worth about 20% of private memory usage when
making PDBs. However, this is not an unmitigated performance win,
because it can be faster to read dense, temporary, heap data than it is
to iterate symbol records in object file backed memory a second time.

Results on release chrome.dll:
peak mem: 5164.89MB -> 4072.19MB (-1,092.7MB, -21.2%)
wall-j1:  0m30.844s -> 0m32.094s (slightly slower)
wall-j3:  0m20.968s -> 0m20.312s (slightly faster)
wall-j8:  0m19.062s -> 0m17.672s (meaningfully faster)

I gathered similar numbers for a debug, component build of content.dll
in Chrome, and the performance impact of this change was in the noise.
The memory usage reduction was visible and similar.

Because of the new parallelism in the PDB commit phase, more cores makes
the new approach faster. I'm assuming that most C++ developer machines
these days are at least quad core, so I think this is a win.

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

[PDB] Remove a couple asserts that are no longer valid now that C13Builders does not use unique_ptr.

2020-05-03T00:31:10+00:00

These asserts used to check that unique_ptr was not null.

This fixes failures from 7af4bb16417deeb1d01e7dbbbb2272f1f46753c6

[PDB] Remove unique_ptr wrapper around C13 line table subsections

2020-05-02T23:35:07+00:00

This accounts for a large portion of the memory allocations in LLD.
This DebugSubsectionRecordBuilder object can be stored directly in
C13Builders, it mostly wraps other subsections.

Remove the container kind field from the object. It is always the same
for all elements in the vector, and we can pass it in during writing.

Make llvm::StringRef to std::string conversions explicit.

2020-01-28T22:25:25+00:00

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.