[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

Cleanup llvm/DebugInfo/PDB headers

accumulated preprocessed size:
before: 1065515095
after: 1065629059

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differenti

Cleanup llvm/DebugInfo/PDB headers

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

show more ...

[llvm] Use = default (NFC)

Fixed some errors detected by PVS Studio

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

This reverts commit bacf9cf2c5cdec3567580e5030c4c82f42b3d745 and
reinstates commit 1a9bd5b81328adf0dd5a8b4f3ad5949463e6

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

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.

show more ...

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

This reverts commit 1a9bd5b81328adf0dd5a8b4f3ad5949463e66da3.

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

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

This reverts commit 1a9bd5b81328adf0dd5a8b4f3ad5949463e66da3.

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

show more ...

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

This reverts commit 5b7aef6eb4b2930971029b984cb2360f7682e5a5 and relands
6529d7c5a45b1b9588e512013b02f891d71bc134.

The

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

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.

show more ...

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

This reverts commit 6529d7c5a45b1b9588e512013b02f891d71bc134.

Reason: Broke the ASan buildbots.
http://lab.llvm.org:801

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

This reverts commit 6529d7c5a45b1b9588e512013b02f891d71bc134.

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

show more ...

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

This is a pretty classic optimization. Instead of processing symbol
records and copying them to temporary storage, do a first pas

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

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

show more ...

[PDB] Simplify API for making section map, NFC

Prevents API misuse described in PR44495

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[PDB] Emit old fpo data to the PDB file.

r342003 added support for emitting FPO data from the
DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB
file. However, that is not the end of t

[PDB] Emit old fpo data to the PDB file.

r342003 added support for emitting FPO data from the
DEBUG_S_FRAMEDATA subsection of the .debug$S section to the PDB
file. However, that is not the end of the story. FPO can end
up in two different destinations in a PDB, each corresponding to
a different FPO data source.

The case handled by r342003 involves copying data from the
DEBUG_S_FRAMEDATA subsection of the .debug$S section to the
"New FPO" stream in the PDB, which is then referred to by the
DBI stream. The case handled by this patch involves copying
records from the .debug$F section of an object file to the "FPO"
stream (or perhaps more aptly, the "Old FPO" stream) in the PDB
file, which is also referred to by the DBI stream.

The formats are largely similar, and the difference is mostly
only visible in masm generated object files, such as some of the
low-level CRT object files like memcpy. MASM doesn't appear to
support writing the DEBUG_S_FRAMEDATA subsection, and instead
just writes these records to the .debug$F section.

Although clang-cl does not emit a .debug$F section ever, lld still
needs to support it so we have good debugging for CRT functions.

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

llvm-svn: 342080

show more ...

[PDB] Write FPO Data to the PDB.

llvm-svn: 342003

[PDB] Correctly use the target machine when writing DBI stream.

Using Config->is64() will treat ARM64 as Amd64, which is incorrect.
Furthermore, there are more esoteric architectures that could
theo

[PDB] Correctly use the target machine when writing DBI stream.

Using Config->is64() will treat ARM64 as Amd64, which is incorrect.
Furthermore, there are more esoteric architectures that could
theoretically be encountered. Just set it directly to the machine
type, which we already know anyway.

llvm-svn: 330157

show more ...

Resubmit "Fix some incorrect fields in our generated PDBs."

This fixes the failing tests. They simply hadn't been updated
to match the new output resulting from this patch.

llvm-svn: 330145

Revert "Fix some incorrect fields in our generated PDBs."

There are a couple of failing tests which slipped under my radar
so I'm reverting this while I attempt to fix.

llvm-svn: 330133

Fix some incorrect fields in our generated PDBs.

Most of these are pretty trivial and obvious. Setting the toolchain
version to 14.11 is perhaps a little questionable, but we've been bitten
in the p

Fix some incorrect fields in our generated PDBs.

Most of these are pretty trivial and obvious. Setting the toolchain
version to 14.11 is perhaps a little questionable, but we've been bitten
in the past where one of our version fields sidn't match MSVC's, and I
definitely don't want to go through that diagnosis again as it was
pretty time consuming and hard to track down.

I found all of these by using llvm-pdbutil export to dump the dbi and
pdb streams to a file, then using fc followed by llvm-pdbutil explain to
explain the mismatched bytes.

There are still some more, these are just the low hanging fruit.

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

llvm-svn: 330130

show more ...

[PDB] Make our PDBs look more like MS PDBs.

When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.

But comparing PDBs is hard be

[PDB] Make our PDBs look more like MS PDBs.

When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.

But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.

This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.

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

llvm-svn: 328348

show more ...

COFF: PDB: Allow multiple modules with the same name.

It is possible for two modules to have the same name if they are
archive members with the same name, or if we are doing LTO (in which
case all m

COFF: PDB: Allow multiple modules with the same name.

It is possible for two modules to have the same name if they are
archive members with the same name, or if we are doing LTO (in which
case all modules will have the name "lto.tmp").

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

llvm-svn: 312744

show more ...

[PDB] Fix section contributions

Summary:
PDB section contributions are supposed to use output section indices and
offsets, not input section indices and offsets.

This allows the debugger to look up

[PDB] Fix section contributions

Summary:
PDB section contributions are supposed to use output section indices and
offsets, not input section indices and offsets.

This allows the debugger to look up the index of the module that it
should look up in the modules stream for symbol information. With this
change, windbg can now find line tables, but it still cannot print local
variables.

Fixes PR34048

Reviewers: zturner

Subscribers: hiraditya, ruiu, llvm-commits

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

llvm-svn: 309987

show more ...

[lld/pdb] Add an empty globals stream.

We don't write any actual symbols to this stream yet, but for
now we just create the stream and hook it up to the appropriate
places and give it a valid header

[lld/pdb] Add an empty globals stream.

We don't write any actual symbols to this stream yet, but for
now we just create the stream and hook it up to the appropriate
places and give it a valid header.

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

llvm-svn: 309608

show more ...