[CodeView Type Merging] Don't keep re-allocating temp serializer.

Previously, every time we wanted to serialize a field list record, we
would create a new copy of FieldListRecordBuilder, which would

[CodeView Type Merging] Don't keep re-allocating temp serializer.

Previously, every time we wanted to serialize a field list record, we
would create a new copy of FieldListRecordBuilder, which would in turn
create a temporary instance of TypeSerializer, which itself had a
std::vector<> that was about 128K in size. So this 128K allocation was
happening every time. We can re-use the same instance over and over, we
just have to clear its internal hash table and seen records list between
each run. This saves us from the constant re-allocations.

This is worth an ~18.5% speed increase (3.75s -> 3.05s) in my tests.

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

llvm-svn: 303919

show more ...

Don't generate line&scope debug info for meta-instructions.

MachineInstructions that don't generate any code (such as
IMPLICIT_DEFs) should not generate any debug info either.

Fixes PR33107.

https

Don't generate line&scope debug info for meta-instructions.

MachineInstructions that don't generate any code (such as
IMPLICIT_DEFs) should not generate any debug info either.

Fixes PR33107.

https://bugs.llvm.org/show_bug.cgi?id=33107

This reapplies r303566 without any modifications. The stage2 build
failures persisted even after reverting this patch, and looking back
through history, it looks like these tests are flaky.

llvm-svn: 303575

show more ...

Revert "Don't generate line&scope debug info for meta-instructions."

This reverts commit r303566 while investigating a stage2 buildbot failure.

llvm-svn: 303570

Don't generate line&scope debug info for meta-instructions.

MachineInstructions that don't generate any code (such as
IMPLICIT_DEFs) should not generate any debug info either.

Fixes PR33107.

https

Don't generate line&scope debug info for meta-instructions.

MachineInstructions that don't generate any code (such as
IMPLICIT_DEFs) should not generate any debug info either.

Fixes PR33107.

https://bugs.llvm.org/show_bug.cgi?id=33107

llvm-svn: 303566

show more ...

Resubmit "[CodeView] Provide a common interface for type collections."

This was originally reverted because it was a breaking a bunch
of bots and the breakage was not surfacing on Windows. After mu

Resubmit "[CodeView] Provide a common interface for type collections."

This was originally reverted because it was a breaking a bunch
of bots and the breakage was not surfacing on Windows. After much
head-scratching this was ultimately traced back to a bug in the
lit test runner related to its pipe handling. Now that the bug
in lit is fixed, Windows correctly reports these test failures,
and as such I have finally (hopefully) fixed all of them in this
patch.

llvm-svn: 303446

show more ...

Revert "[CodeView] Provide a common interface for type collections."

This is a squash of ~5 reverts of, well, pretty much everything
I did today. Something is seriously broken with lit on Windows
r

Revert "[CodeView] Provide a common interface for type collections."

This is a squash of ~5 reverts of, well, pretty much everything
I did today. Something is seriously broken with lit on Windows
right now, and as a result assertions that fire in tests are
triggering failures. I've been breaking non-Windows bots all
day which has seriously confused me because all my tests have
been passing, and after running lit with -a to view the output
even on successful runs, I find out that the tool is crashing
and yet lit is still reporting it as a success!

At this point I don't even know where to start, so rather than
leave the tree broken for who knows how long, I will get this
back to green, and then once lit is fixed on Windows, hopefully
hopefully fix the remaining set of problems for real.

llvm-svn: 303409

show more ...

Fix another warning.

llvm-svn: 303394

[CodeView] Provide a common interface for type collections.

Right now we have multiple notions of things that represent collections of
types. Most commonly used are TypeDatabase, which is supposed t

[CodeView] Provide a common interface for type collections.

Right now we have multiple notions of things that represent collections of
types. Most commonly used are TypeDatabase, which is supposed to keep
mappings from TypeIndex to type name when reading a type stream, which
happens when reading PDBs. And also TypeTableBuilder, which is used to
build up a collection of types dynamically which we will later serialize
(i.e. when writing PDBs).

But often you just want to do some operation on a collection of types, and
you may want to do the same operation on any kind of collection. For
example, you might want to merge two TypeTableBuilders or you might want
to merge two type streams that you loaded from various files.

This dichotomy between reading and writing is responsible for a lot of the
existing code duplication and overlapping responsibilities in the existing
CodeView library classes. For example, after building up a
TypeTableBuilder with a bunch of type records, if we want to dump it we
have to re-invent a bunch of extra glue because our dumper takes a
TypeDatabase or a CVTypeArray, which are both incompatible with
TypeTableBuilder.

This patch introduces an abstract base class called TypeCollection which
is shared between the various type collection like things. Wherever we
previously stored a TypeDatabase& in some common class, we now store a
TypeCollection&.

The advantage of this is that all the details of how the collection are
implemented, such as lazy deserialization of partial type streams, is
completely transparent and you can just treat any collection of types the
same regardless of where it came from.

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

llvm-svn: 303388

show more ...

[CodeView] Simplify the use of visiting type records & streams.

There is often a lot of boilerplate code required to visit a type
record or type stream. The #1 use case is that you have a sequence

[CodeView] Simplify the use of visiting type records & streams.

There is often a lot of boilerplate code required to visit a type
record or type stream. The #1 use case is that you have a sequence
of bytes that represent one or more records, and you want to
deserialize each one, switch on it, and call a callback with the
deserialized record that the user can examine. Currently this
requires at least 6 lines of code:

codeview::TypeVisitorCallbackPipeline Pipeline;
Pipeline.addCallbackToPipeline(Deserializer);
Pipeline.addCallbackToPipeline(MyCallbacks);

codeview::CVTypeVisitor Visitor(Pipeline);
consumeError(Visitor.visitTypeRecord(Record));

With this patch, it becomes one line of code:

consumeError(codeview::visitTypeRecord(Record, MyCallbacks));

This is done by having the deserialization happen internally inside
of the visitTypeRecord function. Since this is occasionally not
desirable, the function provides a 3rd parameter that can be used
to change this behavior.

Hopefully this can significantly reduce the barrier to entry
to using the visitation infrastructure.

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

llvm-svn: 303271

show more ...

IR: Give function GlobalValue::getRealLinkageName() a less misleading name: dropLLVMManglingEscape().

This function gives the wrong answer on some non-ELF platforms in some
cases. The function that

IR: Give function GlobalValue::getRealLinkageName() a less misleading name: dropLLVMManglingEscape().

This function gives the wrong answer on some non-ELF platforms in some
cases. The function that does the right thing lives in Mangler.h. To try to
discourage people from using this function, give it a different name.

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

llvm-svn: 303134

show more ...

[codeview] Check for a DIExpression offset for local variables

Fixes inalloca parameters, which previously all pointed to the same
offset. Extend the test to use llvm-readobj so that we can test the

[codeview] Check for a DIExpression offset for local variables

Fixes inalloca parameters, which previously all pointed to the same
offset. Extend the test to use llvm-readobj so that we can test the
offset in a readable way.

llvm-svn: 302578

show more ...

[CodeView] Reserve TypeDatabase records up front.

Most of the time we know exactly how many type records we
have in a list, and we want to use the visitor to deserialize
them into actual records in

[CodeView] Reserve TypeDatabase records up front.

Most of the time we know exactly how many type records we
have in a list, and we want to use the visitor to deserialize
them into actual records in a database. Previously we were
just using push_back() every time without reserving the space
up front in the vector. This is obviously terrible from a
performance standpoint, and it's not uncommon to have PDB
files with half a million type records, where the performance
degredation was quite noticeable.

llvm-svn: 302302

show more ...

DebugInfo: elide type index entries for synthetic types

Compiler emitted synthetic types may not have an associated DIFile
(translation unit). In such a case, when generating CodeView debug type
in

DebugInfo: elide type index entries for synthetic types

Compiler emitted synthetic types may not have an associated DIFile
(translation unit). In such a case, when generating CodeView debug type
information, we would attempt to compute an absolute filepath which
would result in a segfault due to a NULL DIFile*. If there is no source
file associated with the type, elide the type index entry for the type
and record the type information. This actually results in higher
fidelity debug information than clang/C2 as of this writing.

Resolves PR32668!

llvm-svn: 302085

show more ...

[PDB/CodeView] Read/write codeview inlinee line information.

Previously we wrote line information and file checksum
information, but we did not write information about inlinee
lines and functions.

[PDB/CodeView] Read/write codeview inlinee line information.

Previously we wrote line information and file checksum
information, but we did not write information about inlinee
lines and functions. This patch adds support for that.

llvm-svn: 301936

show more ...

Rename some PDB classes.

We have a lot of very similarly named classes related to
dealing with module debug info. This patch has NFC, it just
renames some classes to be more descriptive (albeit sli

Rename some PDB classes.

We have a lot of very similarly named classes related to
dealing with module debug info. This patch has NFC, it just
renames some classes to be more descriptive (albeit slightly
more to type). The mapping from old to new class names is as
follows:

Old | New
ModInfo | DbiModuleDescriptor
ModuleSubstream | ModuleDebugFragment
ModStream | ModuleDebugStream

With the corresponding Builder classes renamed accordingly.

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

llvm-svn: 301555

show more ...

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram b

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram by rearranging the operands such that containing type,
template params, and thrown types come last, and are only allocated
when they are non-null (or followed by non-null operands).

This patch also eliminates the entirely unused DisplayName operand.

This saves up to 4 pointer operands per DISubprogram. (I tried
measuring the effect on peak memory usage on an LTO link of an X86
llc, but the results were very noisy).

This reapplies r301498 with an attempted workaround for g++.

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

llvm-svn: 301501

show more ...

Revert "Turn DISubprogram into a variable-length node."

This reverts commit r301498 while investigating bot breakage.

llvm-svn: 301499

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram b

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram by rearranging the operands such that containing type,
template params, and thrown types come last, and are only allocated
when they are non-null (or followed by non-null operands).

This patch also eliminates the entirely unused DisplayName operand.

This saves up to 4 pointer operands per DISubprogram. (I tried
measuring the effect on peak memory usage on an LTO link of an X86
llc, but the results were very noisy).

llvm-svn: 301498

show more ...

Distinguish between code pointer size and DataLayout::getPointerSize() in DWARF info generation

llvm-svn: 300463

Remove redundant check for nullptr.

llvm-svn: 298866

[codeview] Don't assert when the user violates the ODR

If we have an array of a user-defined aggregates for which there was an
ODR violation, then the array size will not necessarily match the numbe

[codeview] Don't assert when the user violates the ODR

If we have an array of a user-defined aggregates for which there was an
ODR violation, then the array size will not necessarily match the number
of elements times the size of the element.

Fixes PR32383

llvm-svn: 298750

show more ...

[Support] Move Stream library from MSF -> Support.

After several smaller patches to get most of the core improvements
finished up, this patch is a straight move and header fixup of
the source.

Diff

[Support] Move Stream library from MSF -> Support.

After several smaller patches to get most of the core improvements
finished up, this patch is a straight move and header fixup of
the source.

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

llvm-svn: 296810

show more ...

[PDB] Make streams carry their own endianness.

Before the endianness was specified on each call to read
or write of the StreamReader / StreamWriter, but in practice
it's extremely rare for streams t

[PDB] Make streams carry their own endianness.

Before the endianness was specified on each call to read
or write of the StreamReader / StreamWriter, but in practice
it's extremely rare for streams to have data encoded in
multiple different endiannesses, so we should optimize for the
99% use case.

This makes the code cleaner and more general, but otherwise
has NFC.

llvm-svn: 296415

show more ...

[PDB] Partial resubmit of r296215, which improved PDB Stream Library.

This was reverted because it was breaking some builds, and
because of incorrect error code usage. Since the CL was
large and co

[PDB] Partial resubmit of r296215, which improved PDB Stream Library.

This was reverted because it was breaking some builds, and
because of incorrect error code usage. Since the CL was
large and contained many different things, I'm resubmitting
it in pieces.

This portion is NFC, and consists of:

1) Renaming classes to follow a consistent naming convention.
2) Fixing the const-ness of the interface methods.
3) Adding detailed doxygen comments.
4) Fixing a few instances of passing `const BinaryStream& X`. These
are now passed as `BinaryStreamRef X`.

llvm-svn: 296394

show more ...

Revert r296215, "[PDB] General improvements to Stream library." and followings.

r296215, "[PDB] General improvements to Stream library."
r296217, "Disable BinaryStreamTest.StreamReaderObject tempora

Revert r296215, "[PDB] General improvements to Stream library." and followings.

r296215, "[PDB] General improvements to Stream library."
r296217, "Disable BinaryStreamTest.StreamReaderObject temporarily."
r296220, "Re-enable BinaryStreamTest.StreamReaderObject."
r296244, "[PDB] Disable some tests that are breaking bots."
r296249, "Add static_cast to silence -Wc++11-narrowing."

std::errc::no_buffer_space should be used for OS-oriented errors for socket transmission.
(Seek discussions around llvm/xray.)

I could substitute s/no_buffer_space/others/g, but I revert whole them ATM.

Could we define and use LLVM errors there?

llvm-svn: 296258

show more ...