|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, 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, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, 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, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
e0e687a6 |
| 20-Jun-2022 |
Kazu Hirata <[email protected]> |
[llvm] Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
| #
81cde474 |
| 04-Feb-2022 |
serge-sans-paille <[email protected]> |
Cleanup LLVMDebugInfoCodeView headers
Major user-facing changes:
Many headers in llvm/DebugInfo/CodeView no longer include llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h, th
Cleanup LLVMDebugInfoCodeView headers
Major user-facing changes:
Many headers in llvm/DebugInfo/CodeView no longer include llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h, those headers may need to be included manually.
Several headers in llvm/DebugInfo/CodeView no longer include llvm/DebugInfo/CodeView/EnumTables.h or llvm/DebugInfo/CodeView/CodeView.h, those headers may need to be included manually.
Some statistics: $ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/DebugInfo/CodeView/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l after: 2794466 before: 2832765
Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/
Differential Revision: https://reviews.llvm.org/D119092
show more ...
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
c8dedfe2 |
| 02-Jan-2021 |
Nico Weber <[email protected]> |
fix typos to cycle bots
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6 |
|
| #
5d4c1c00 |
| 23-Mar-2020 |
David Blaikie <[email protected]> |
Roll an expression into an assert to remove the need for a (void) cast.
|
|
Revision tags: llvmorg-10.0.0-rc5 |
|
| #
b5aaa609 |
| 13-Mar-2020 |
Richard Smith <[email protected]> |
Fix "unused variable" warning in NDEBUG builds.
|
| #
a7325298 |
| 13-Mar-2020 |
Alexandre Ganea <[email protected]> |
[CodeView] Align type records on 4-bytes when emitting PDBs
When emitting PDBs, the TypeStreamMerger class is used to merge .debug$T records from the input .OBJ files into the output .PDB stream. Re
[CodeView] Align type records on 4-bytes when emitting PDBs
When emitting PDBs, the TypeStreamMerger class is used to merge .debug$T records from the input .OBJ files into the output .PDB stream. Records in .OBJs are not required to be aligned on 4-bytes, and "The Netwide Assembler 2.14" generates non-aligned records.
When compiling with -DLLVM_ENABLE_ASSERTIONS=ON, an assert was triggered in MergingTypeTableBuilder when non-ghash merging was used. With ghash merging there was no assert. As a result, LLD could potentially generate a non-aligned TPI stream.
We now align records on 4-bytes when record indices are remapped, in TypeStreamMerger::remapIndices().
Differential Revision: https://reviews.llvm.org/D75081
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2 |
|
| #
783db788 |
| 25-Nov-2019 |
Reid Kleckner <[email protected]> |
[PDB] Print the most redundant type record indices with /summary
Summary: I used this information to motivate splitting up the Intrinsic::ID enum (5d986953c8b917bacfaa1f800fc1e242559f76be) and addin
[PDB] Print the most redundant type record indices with /summary
Summary: I used this information to motivate splitting up the Intrinsic::ID enum (5d986953c8b917bacfaa1f800fc1e242559f76be) and adding a key method to clang::Sema (586f65d31f32ca6bc8cfdb8a4f61bee5057bf6c8) which saved a fair amount of object file size.
Example output for clang.pdb:
Top 10 types responsible for the most TPI input bytes: index total bytes count size 0x3890: 8,671,220 = 1,805 * 4,804 0xE13BE: 5,634,720 = 252 * 22,360 0x6874C: 5,181,600 = 408 * 12,700 0x2A1F: 4,520,528 = 1,574 * 2,872 0x64BFF: 4,024,020 = 469 * 8,580 0x1123: 4,012,020 = 2,157 * 1,860 0x6952: 3,753,792 = 912 * 4,116 0xC16F: 3,630,888 = 633 * 5,736 0x69DD: 3,601,160 = 985 * 3,656 0x678D: 3,577,904 = 319 * 11,216
In this case, we can see that record 0x3890 is responsible for ~8MB of total object file size for objects in clang.
The user can then use llvm-pdbutil to find out what the record is:
$ llvm-pdbutil dump -types -type-index 0x3890 Types (TPI Stream) ============================================================ Showing 1 records. 0x3890 | LF_FIELDLIST [size = 4804] - LF_STMEMBER [name = `WORDTYPE_MAX`, type = 0x1001, attrs = public] - LF_MEMBER [name = `U`, Type = 0x37F0, offset = 0, attrs = private] - LF_MEMBER [name = `BitWidth`, Type = 0x0075 (unsigned), offset = 8, attrs = private] - LF_METHOD [name = `APInt`, # overloads = 8, overload list = 0x3805] ...
In this case, we can see that these are members of the APInt class, which is emitted in 1805 object files.
The next largest type is ASTContext:
$ llvm-pdbutil dump -types -type-index 0xE13BE bin/clang.pdb 0xE13BE | LF_FIELDLIST [size = 22360] - LF_BCLASS type = 0x653EA, offset = 0, attrs = public - LF_MEMBER [name = `Types`, Type = 0x653EB, offset = 8, attrs = private] - LF_MEMBER [name = `ExtQualNodes`, Type = 0x653EC, offset = 24, attrs = private] - LF_MEMBER [name = `ComplexTypes`, Type = 0x653ED, offset = 48, attrs = private] - LF_MEMBER [name = `PointerTypes`, Type = 0x653EE, offset = 72, attrs = private] ...
ASTContext only appears 252 times, but the list of members is long, and must be repeated everywhere it is used.
This was the output before I split Intrinsic::ID:
Top 10 types responsible for the most TPI input: 0x686C: 69,823,920 = 1,070 * 65,256 0x686D: 69,819,640 = 1,070 * 65,252 0x686E: 69,819,640 = 1,070 * 65,252 0x686B: 16,371,000 = 1,070 * 15,300 ...
These records were all lists of intrinsic enums.
Reviewers: MaskRay, ruiu
Subscribers: mgrang, zturner, thakis, hans, akhuang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71437
show more ...
|
|
Revision tags: llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
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 ...
|
| #
90f4b94d |
| 07-Jan-2019 |
Alexandre Ganea <[email protected]> |
[CodeView] More appropriate name and type for a Microsoft precompiled headers parameter. NFC
llvm-svn: 350520
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
71c43cea |
| 05-Nov-2018 |
Alexandre Ganea <[email protected]> |
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs
This change allows for link-time merging of debugging information from Microsoft precompiled types OBJs compiled with cl.exe /Z7 /
[COFF][LLD] Add link support for Microsoft precompiled headers OBJs
This change allows for link-time merging of debugging information from Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu.
This fixes llvm.org/PR34278
Differential Revision: https://reviews.llvm.org/D45213
llvm-svn: 346154
show more ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3 |
|
| #
6a7efef4 |
| 31-Aug-2018 |
Alexandre Ganea <[email protected]> |
[DebugInfo] Common behavior for error types
Following D50807, and heading towards D50664, this intermediary change does the following:
1. Upgrade all custom Error types in llvm/trunk/lib/DebugInfo/
[DebugInfo] Common behavior for error types
Following D50807, and heading towards D50664, this intermediary change does the following:
1. Upgrade all custom Error types in llvm/trunk/lib/DebugInfo/ to use the new StringError behavior (D50807). 2. Implement std::is_error_code_enum and make_error_code() for DebugInfo error enumerations. 3. Rename GenericError -> PDBError (the file will be renamed in a subsequent commit) 4. Update custom error messages to follow the same formatting: (\w\s*)+\. 5. Keep generic "file not found" (ENOENT) errors as they are in PDB code. Previously, there used to be a custom enumeration for that purpose. 6. Remove a few extraneous LF in log() implementations. Printing LF is a responsability at a higher level, not at the error level.
Differential Revision: https://reviews.llvm.org/D51499
llvm-svn: 341228
show more ...
|
|
Revision tags: llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
| #
0bb8e891 |
| 30-Jul-2018 |
Alexandre Ganea <[email protected]> |
This fixes a crash when a second pass is required for the Codeview Type merging *and* the index points outside of the table (which should lead to an error being printed).
This occurs currently until
This fixes a crash when a second pass is required for the Codeview Type merging *and* the index points outside of the table (which should lead to an error being printed).
This occurs currently until MS precompiled headers .obj is added (see D45213)
Differential Revision: https://reviews.llvm.org/D50006
llvm-svn: 338308
show more ...
|
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2 |
|
| #
07d80377 |
| 30-Jan-2018 |
Zachary Turner <[email protected]> |
[CodeView] Micro-optimizations to speed up type merging.
Based on a profile, a couple of hot spots were identified in the main type merging loop. The code was simplified, a few loops were re-arrang
[CodeView] Micro-optimizations to speed up type merging.
Based on a profile, a couple of hot spots were identified in the main type merging loop. The code was simplified, a few loops were re-arranged, and some outlined functions were inlined. This speeds up type merging by a decent amount, shaving around 3-4 seconds off of a 40 second link in my test case.
Differential Revision: https://reviews.llvm.org/D42559
llvm-svn: 323790
show more ...
|
| #
1bc2ce6b |
| 18-Jan-2018 |
Zachary Turner <[email protected]> |
Speed up iteration of CodeView record streams.
There's some abstraction overhead in the underlying mechanisms that were being used, and it was leading to an abundance of small but not-free copies be
Speed up iteration of CodeView record streams.
There's some abstraction overhead in the underlying mechanisms that were being used, and it was leading to an abundance of small but not-free copies being made. This showed up on a profile. Eliminating this and going back to a low-level byte-based implementation speeds up lld with /DEBUG between 10 and 15%.
Differential Revision: https://reviews.llvm.org/D42148
llvm-svn: 322871
show more ...
|
|
Revision tags: llvmorg-6.0.0-rc1 |
|
| #
0d07a8e9 |
| 14-Dec-2017 |
Zachary Turner <[email protected]> |
[COFF] Teach LLD to use the COFF .debug$H section.
This adds the /DEBUG:GHASH option to LLD which will look for the existence of .debug$H sections in linker inputs and use them to accelerate type me
[COFF] Teach LLD to use the COFF .debug$H section.
This adds the /DEBUG:GHASH option to LLD which will look for the existence of .debug$H sections in linker inputs and use them to accelerate type merging. The clang-cl side has already been added, so this completes the work necessary to begin experimenting with this feature.
Differential Revision: https://reviews.llvm.org/D40980
llvm-svn: 320719
show more ...
|
| #
0c169bf7 |
| 13-Dec-2017 |
Michael Zolotukhin <[email protected]> |
Remove redundant includes from lib/DebugInfo.
llvm-svn: 320620
|
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3 |
|
| #
ca6dbf14 |
| 30-Nov-2017 |
Zachary Turner <[email protected]> |
Split TypeTableBuilder into two classes.
llvm-svn: 319456
|
| #
52d036e6 |
| 29-Nov-2017 |
Zachary Turner <[email protected]> |
[CodeView] Factor some code out of TypeTableBuilder.
This class had some code that would automatically remap type indices before hashing and serializing. The only caller of this method was the Type
[CodeView] Factor some code out of TypeTableBuilder.
This class had some code that would automatically remap type indices before hashing and serializing. The only caller of this method was the TypeStreamMerger anyway, and the method doesn't make general sense, and prevents making certain future improvements to the class. So, factoring this up one level into the TypeStreamMerger where it belongs.
llvm-svn: 319377
show more ...
|
|
Revision tags: llvmorg-5.0.1-rc2 |
|
| #
6900de1d |
| 28-Nov-2017 |
Zachary Turner <[email protected]> |
[CodeView] Refactor / Rewrite TypeSerializer and TypeTableBuilder.
The motivation behind this patch is that future directions require us to be able to compute the hash value of records independently
[CodeView] Refactor / Rewrite TypeSerializer and TypeTableBuilder.
The motivation behind this patch is that future directions require us to be able to compute the hash value of records independently of actually using them for de-duplication.
The current structure of TypeSerializer / TypeTableBuilder being a single entry point that takes an unserialized type record, and then hashes and de-duplicates it is not flexible enough to allow this.
At the same time, the existing TypeSerializer is already extremely complex for this very reason -- it tries to be too many things. In addition to serializing, hashing, and de-duplicating, ti also supports splitting up field list records and adding continuations. All of this functionality crammed into this one class makes it very complicated to work with and hard to maintain.
To solve all of these problems, I've re-written everything from scratch and split the functionality into separate pieces that can easily be reused. The end result is that one class TypeSerializer is turned into 3 new classes SimpleTypeSerializer, ContinuationRecordBuilder, and TypeTableBuilder, each of which in isolation is simple and straightforward.
A quick summary of these new classes and their responsibilities are:
- SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of bytes. Does not do any hashing. Every time you call it, it will re-serialize and return bytes again. The same instance can be re-used over and over to avoid re-allocations, and in exchange for this optimization the bytes returned by the serializer only live until the caller attempts to serialize a new record.
- ContinuationRecordBuilder : Turns a FieldList-like record into a series of fragments. Does not do any hashing. Like SimpleTypeSerializer, returns references to privately owned bytes, so the storage is invalidated as soon as the caller tries to re-use the instance. Works equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a long-standing theoretical limitation of the previous implementation.
- TypeTableBuilder : Accepts sequences of bytes that the user has already serialized, and inserts them by de-duplicating with a hash table. For the sake of convenience and efficiency, this class internally stores a SimpleTypeSerializer so that it can accept unserialized records. The same is not true of ContinuationRecordBuilder. The user is required to create their own instance of ContinuationRecordBuilder.
Differential Revision: https://reviews.llvm.org/D40518
llvm-svn: 319198
show more ...
|
|
Revision tags: llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1 |
|
| #
3167480c |
| 17-Jul-2017 |
Reid Kleckner <[email protected]> |
[codeview] Don't use the type visitor to merge types
Summary: This didn't do much to speed things up, but it implements a FIXME, and I think it's a nice simplification. We don't need the record kind
[codeview] Don't use the type visitor to merge types
Summary: This didn't do much to speed things up, but it implements a FIXME, and I think it's a nice simplification. We don't need the record kind switch. We're doing that ourselves.
Reviewers: ruiu, inglorion
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35496
llvm-svn: 308213
show more ...
|
| #
a842cd75 |
| 17-Jul-2017 |
Reid Kleckner <[email protected]> |
[codeview] Remove TypeServerHandler and PDBTypeServerHandler
Summary: Instead of wiring these through the CVTypeVisitor interface, clients should inspect the CVTypeArray before visiting it and poten
[codeview] Remove TypeServerHandler and PDBTypeServerHandler
Summary: Instead of wiring these through the CVTypeVisitor interface, clients should inspect the CVTypeArray before visiting it and potentially load up the type server's TPI stream if they need it.
No tests relied on this functionality because LLD was the only client.
Reviewers: ruiu
Subscribers: mgorny, hiraditya, zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D35394
llvm-svn: 308212
show more ...
|
| #
6597c28d |
| 13-Jul-2017 |
Reid Kleckner <[email protected]> |
[PDB] Fix type server handling for archives
Summary: This fixes type indices for SDK or CRT static archives. Previously we'd try to look next to the archive object file path, which would not exist o
[PDB] Fix type server handling for archives
Summary: This fixes type indices for SDK or CRT static archives. Previously we'd try to look next to the archive object file path, which would not exist on the local machine.
Also error out if we can't resolve a type server record. Hypothetically we can recover from this error by discarding debug info for this object, but that is not yet implemented.
Reviewers: ruiu, amccarth
Subscribers: aprantl, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D35369
llvm-svn: 307946
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
f2110283 |
| 25-May-2017 |
Zachary Turner <[email protected]> |
Remove unused member.
llvm-svn: 303942
|
| #
fed467ee |
| 25-May-2017 |
Zachary Turner <[email protected]> |
[CV Type Merging] Find nested type indices faster.
Merging two type streams is one of the most time consuming parts of generating a PDB, and as such it needs to be as fast as possible. The visitor
[CV Type Merging] Find nested type indices faster.
Merging two type streams is one of the most time consuming parts of generating a PDB, and as such it needs to be as fast as possible. The visitor abstractions used for interoperating nicely with many different types of inputs and outputs have been used widely and help greatly for testability and implementing tools, but the abstractions build up and get in the way of performance.
This patch removes all of the visitation stuff from the type stream merger, essentially re-inventing the leaf / member switch and loop, but at a very low level. This allows us many other optimizations, such as not actually deserializing *any* records (even member records which don't describe their own length), as the operation of "figure out how long this record is" is somewhat faster than "figure out how long this record *and* get all its fields out". Furthermore, whereas before we had to deserialize, re-write type indices, then re-serialize, now we don't have to do any of those 3 steps. We just find out where the type indices are and pull them directly out of the byte stream and re-write them.
This is worth a 50-60% performance increase. On top of all other optimizations that have been applied this week, I now get the following numbers when linking lld.exe and lld.pdb
MSVC: 25.67s Before This Patch: 18.59s After This Patch: 8.92s
So this is a huge performance win.
Differential Revision: https://reviews.llvm.org/D33564
llvm-svn: 303935
show more ...
|
| #
7f97c362 |
| 25-May-2017 |
Zachary Turner <[email protected]> |
[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 ...
|