History log of /llvm-project/llvm/lib/Bitcode/Reader/BitcodeReader.cpp (Results 626 – 650 of 1334)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


1...<<21222324252627282930>>...54