#
7457ecbe |
| 30-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
BitcodeReader: Fix weird whitespace, NFC
llvm-svn: 264822
|
#
b703c77b |
| 29-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Remove post-pass metadata linking support
Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there
[ThinLTO] Remove post-pass metadata linking support
Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there is no longer a need to link metadata as a postpass, and all users have been removed.
This essentially reverts r255909 and follow-on fixes.
llvm-svn: 264763
show more ...
|
#
f46262e0 |
| 29-Mar-2016 |
Manman Ren <manman.ren@gmail.com> |
Swift Calling Convention: add swiftself attribute.
Differential Revision: http://reviews.llvm.org/D17866
llvm-svn: 264754
|
#
bb7ce3b8 |
| 29-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
BitcodeReader: Allow METADATA_STRINGS to only have !""
Support parsing a METADATA_STRINGS record that only has a single piece of metadata, !"". Fixes a corner case in r264551.
llvm-svn: 264699
|
#
6565a0d4 |
| 27-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a bit of a redesign.
Firstly, avoid splitting the big blob
Reapply ~"Bitcode: Collect all MDString records into a single blob"
Spiritually reapply commit r264409 (reverted in r264410), albeit with a bit of a redesign.
Firstly, avoid splitting the big blob into multiple chunks of strings.
r264409 imposed an arbitrary limit to avoid a massive allocation on the shared 'Record' SmallVector. The bug with that commit only reproduced when there were more than "chunk-size" strings. A test for this would have been useless long-term, since we're liable to adjust the chunk-size in the future.
Thus, eliminate the motivation for chunk-ing by storing the string sizes in the blob. Here's the layout:
vbr6: # of strings vbr6: offset-to-blob blob: [vbr6]: string lengths [char]: concatenated strings
Secondly, make the output of llvm-bcanalyzer readable.
I noticed when debugging r264409 that llvm-bcanalyzer was outputting a massive blob all in one line. Past a small number, the strings were impossible to split in my head, and the lines were way too long. This version adds support in llvm-bcanalyzer for pretty-printing.
<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 { 'abc' 'def' 'ghi' }
From the original commit:
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this should (a) slightly reduce bitcode size, since there is less record overhead, and (b) greatly improve reading speed, since blobs are super cheap to deserialize.
llvm-svn: 264551
show more ...
|
#
fc811004 |
| 25-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
Revert "Bitcode: Collect all MDString records into a single blob"
This reverts commit r264409 since it failed to bootstrap: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/
Revert "Bitcode: Collect all MDString records into a single blob"
This reverts commit r264409 since it failed to bootstrap: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/
llvm-svn: 264410
show more ...
|
#
fdbf0a5a |
| 25-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
Bitcode: Collect all MDString records into a single blob
Optimize output of MDStrings in bitcode. This emits them in big blocks (currently 1024) in a pair of records: - BULK_STRING_SIZES: the siz
Bitcode: Collect all MDString records into a single blob
Optimize output of MDStrings in bitcode. This emits them in big blocks (currently 1024) in a pair of records: - BULK_STRING_SIZES: the sizes of the strings in the block, and - BULK_STRING_DATA: a single blob, which is the concatenation of all the strings.
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this should (a) slightly reduce bitcode size, since there is less record overhead, and (b) greatly improve reading speed, since blobs are super cheap to deserialize.
I needed to add support for blobs to streaming input to get the test suite passing. - StreamingMemoryObject::getPointer reads ahead and returns the address of the blob. - To avoid a possible reallocation of StreamingMemoryObject::Bytes, BitstreamCursor::readRecord needs to move the call to JumpToEnd forward so that getPointer is the last bitstream operation.
llvm-svn: 264409
show more ...
|
#
68f56243 |
| 25-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
Bitcode: Stop using MODULE_CODE_METADATA_VALUES
The motivation for MODULE_CODE_METADATA_VALUES was to enable an -flto=thin scheme where:
1. First, one function is cherry-picked from a bitcode file
Bitcode: Stop using MODULE_CODE_METADATA_VALUES
The motivation for MODULE_CODE_METADATA_VALUES was to enable an -flto=thin scheme where:
1. First, one function is cherry-picked from a bitcode file. 2. Later, another function is cherry-picked. 3. Later, ... 4. Finally, the metadata needed by all the previous functions is loaded.
This was abandoned in favour of:
1. Calculate the superset of functions needed from a Module. 2. Link all functions at once.
Delayed metadata reading no longer serves a purpose. It also adds a few complication, since we can't count on metadata being properly parsed when exiting the BitcodeReader. After discussing with Teresa, we agreed to remove it.
The code that depended on this was removed/updated in r264326.
llvm-svn: 264378
show more ...
|
#
efe16c8e |
| 25-Mar-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
IR: Stop upgrading !llvm.loop attachments via MDString
Remove logic to upgrade !llvm.loop by changing the MDString tag directly. This old logic would check (and change) arbitrary strings that had n
IR: Stop upgrading !llvm.loop attachments via MDString
Remove logic to upgrade !llvm.loop by changing the MDString tag directly. This old logic would check (and change) arbitrary strings that had nothing to do with loop metadata. Instead, check !llvm.loop attachments directly, and change which strings get attached.
Rather than updating the assembly-based upgrade, drop it entirely. It has been quite a while since we supported upgrading textual IR.
llvm-svn: 264373
show more ...
|
#
ae341c6e |
| 17-Mar-2016 |
Justin Bogner <mail@justinbogner.com> |
Bitcode: Error out instead of crashing on corrupt metadata
I hit a crash in the bitcode reader on some corrupt input where an MDString had somehow been attached to an instruction instead of an MDNod
Bitcode: Error out instead of crashing on corrupt metadata
I hit a crash in the bitcode reader on some corrupt input where an MDString had somehow been attached to an instruction instead of an MDNode. This input is pretty bogus, but we shouldn't be crashing on bad input here.
This change adds error handling in all of the places where we currently have unchecked casts from Metadata to MDNode, which means we'll error out instead of crashing for that sort of input.
Unfortunately, I don't have tests. Hitting this requires flipping bits in the input bitcode, and committing corrupt binary files to catch these cases is a bit too opaque and unmaintainable.
llvm-svn: 263742
show more ...
|
#
671d0dda |
| 16-Mar-2016 |
Chris Bieneman <beanz@apple.com> |
Upgrade TBAA *before* upgrading intrinsics
Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't
Upgrade TBAA *before* upgrading intrinsics
Summary: If TBAA is on an intrinsic and it gets upgraded and drops the TBAA we hit an odd assert. We should just upgrade the TBAA first because it doesn't have side-effects.
Reviewers: reames, apilipenko, manmanren
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18229
llvm-svn: 263673
show more ...
|
#
b43027d1 |
| 15-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
Move global ID computation from Function to GlobalValue (NFC)
Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving t
Move global ID computation from Function to GlobalValue (NFC)
Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving these methods to the GlobalValue class.
llvm-svn: 263524
show more ...
|
#
26ab5772 |
| 15-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Renaming of function index to module summary index (NFC)
(Resubmitting after fixing missing file issue)
With the changes in r263275, there are now more than just functions in the summary.
[ThinLTO] Renaming of function index to module summary index (NFC)
(Resubmitting after fixing missing file issue)
With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes.
A companion clang patch will immediately succeed this patch to reflect this renaming.
llvm-svn: 263513
show more ...
|
#
cec0cae3 |
| 14-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"
This reverts commit r263490. Missed a file.
llvm-svn: 263493
|
#
892920b3 |
| 14-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Renaming of function index to module summary index (NFC)
With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (star
[ThinLTO] Renaming of function index to module summary index (NFC)
With the changes in r263275, there are now more than just functions in the summary. Completed the renaming of data structures (started in r263275) to reflect the wider scope. In particular, changed the FunctionIndex* data structures to ModuleIndex*, and renamed related variables and comments. Also renamed the files to reflect the changes.
A companion clang patch will immediately succeed this patch to reflect this renaming.
llvm-svn: 263490
show more ...
|
#
76a1c1d0 |
| 11-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Support for reference graph in per-module and combined summary.
Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in
[ThinLTO] Support for reference graph in per-module and combined summary.
Summary: This patch adds support for including a full reference graph including call graph edges and other GV references in the summary.
The reference graph edges can be used to make importing decisions without materializing any source modules, can be used in the plugin to make file staging decisions for distributed build systems, and is expected to have other uses.
The call graph edges are recorded in each function summary in the bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when there is PGO, where the ValueId can be mapped to the function GUID via the ValueSymbolTable. In the function index in memory, the call graph edges reference the target via the CalleeGUID instead of the CalleeValueId.
The reference graph edges are recorded in each summary record with a list of referenced value IDs, which can be mapped to value GUID via the ValueSymbolTable.
Addtionally, a new summary record type is added to record references from global variable initializers. A number of bitcode records and data structures have been renamed to reflect the newly expanded scope of the summary beyond functions. More cleanup will follow.
Reviewers: joker.eph, davidxl
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17212
llvm-svn: 263275
show more ...
|
Revision tags: llvmorg-3.8.0 |
|
#
bbe05450 |
| 24-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Add missing breaks when parsing summaries (NFC)
This wasn't causing a correctness issue, but was causing extra duplicate entries to be added to the SummaryMap.
llvm-svn: 261757
|
Revision tags: llvmorg-3.8.0-rc3 |
|
#
e1164de5 |
| 10-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
Restore "[ThinLTO] Use MD5 hash in function index." with fix
This restores commit r260408, along with a fix for a bot failure.
The bot failure was caused by dereferencing a unique_ptr in the same c
Restore "[ThinLTO] Use MD5 hash in function index." with fix
This restores commit r260408, along with a fix for a bot failure.
The bot failure was caused by dereferencing a unique_ptr in the same call instruction parameter list where it was passed via std::move. Apparently due to luck this was not exposed when I built the compiler with clang, only with gcc.
llvm-svn: 260442
show more ...
|
#
89f38fb5 |
| 10-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
Revert "[ThinLTO] Use MD5 hash in function index." due to bot failure
This reverts commit r260408. Bot failure that I need to investigate.
llvm-svn: 260412
|
#
0919a840 |
| 10-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Use MD5 hash in function index.
Summary: This patch uses the lower 64-bits of the MD5 hash of a function name as a GUID in the function index, instead of storing function names. Any local
[ThinLTO] Use MD5 hash in function index.
Summary: This patch uses the lower 64-bits of the MD5 hash of a function name as a GUID in the function index, instead of storing function names. Any local functions are first given a global name by prepending the original source file name. This is the same naming scheme and GUID used by PGO in the indexed profile format.
This change has a couple of benefits. The primary benefit is size reduction in the combined index file, for example 483.xalancbmk's combined index file was reduced by around 70%. It should also result in memory savings for the index file in memory, as the in-memory map is also indexed by the hash instead of the string.
Second, this enables integration with indirect call promotion, since the indirect call profile targets are recorded using the same global naming convention and hash. This will enable the function importer to easily locate function summaries for indirect call profile targets to enable their import and subsequent promotion.
The original source file name is recorded in the bitcode in a new module-level record for use in the ThinLTO backend pipeline.
Reviewers: davidxl, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17028
llvm-svn: 260408
show more ...
|
#
79d4e2f3 |
| 10-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
Fix VST_CODE_* bitcode id comments (NFC)
llvm-svn: 260382
|
#
5e22e446 |
| 06-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Include linkage type in function summary
Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually
[ThinLTO] Include linkage type in function summary
Summary: Adds the linkage type to both the per-module and combined function summaries, which subsumes the current islocal bit. This will eventually be used to optimized linkage types based on global summary-based analysis.
Reviewers: joker.eph
Subscribers: joker.eph, davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D16943
llvm-svn: 259993
show more ...
|
Revision tags: llvmorg-3.8.0-rc2 |
|
#
6ac3f739 |
| 26-Jan-2016 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
Fix Clang-tidy modernize-use-nullptr and modernize-use-override warnings; other minor fixes.
Differential revision: reviews.llvm.org/D16568
llvm-svn: 258831
|
#
6f508afc |
| 21-Jan-2016 |
Teresa Johnson <tejohnson@google.com> |
[ThinLTO] Avoid unnecesary hash lookups during metadata linking (NFC)
Replace sequences of count() followed by operator[] with either find() or insert(), depending on the context.
llvm-svn: 258405
|
#
1030d68e |
| 20-Jan-2016 |
George Burgess IV <george.burgess.iv@gmail.com> |
Fix typo in an error string. NFC.
llvm-svn: 258357
|