History log of /llvm-project/llvm/lib/Bitcode/Reader/BitcodeReader.cpp (Results 576 – 600 of 1334)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 036e73c8 05-Jun-2016 Filipe Cabecinhas <me@filcab.net>

[BitCode] Make sure storeatomic's argument is an actual PointerType

llvm-svn: 271850


# fc2a3c98 05-Jun-2016 Filipe Cabecinhas <me@filcab.net>

[BitCode] Diagnose GEPs with no indices

llvm-svn: 271849


# 2849b48f 05-Jun-2016 Filipe Cabecinhas <me@filcab.net>

[BitCode] Don't allow constants of void type.

llvm-svn: 271848


Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1
# 382d81ca 01-Jun-2016 Peter Collingbourne <peter@pcc.me.uk>

IR: Allow multiple global metadata attachments with the same type.

This will be necessary to allow the global merge pass to attach
multiple debug info metadata nodes to global variables once we reve

IR: Allow multiple global metadata attachments with the same type.

This will be necessary to allow the global merge pass to attach
multiple debug info metadata nodes to global variables once we reverse
the edge from DIGlobalVariable to GlobalVariable.

Differential Revision: http://reviews.llvm.org/D20414

llvm-svn: 271358

show more ...


# cceae7fe 31-May-2016 Peter Collingbourne <peter@pcc.me.uk>

Add support for metadata attachments for global variables.

This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features

Add support for metadata attachments for global variables.

This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features to use
these new attachments.

Differential Revision: http://reviews.llvm.org/D20074

llvm-svn: 271348

show more ...


# 728f4448 29-May-2016 Benjamin Kramer <benny.kra@googlemail.com>

Remove some 'const' specifiers that do nothing but prevent moving the argument.

Found by clang-tidy's misc-move-const-arg. While there drop some
obsolete c_str() calls.

llvm-svn: 271181


# 82de7d32 27-May-2016 Benjamin Kramer <benny.kra@googlemail.com>

Apply clang-tidy's misc-move-constructor-init throughout LLVM.

No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270997


# b5d7ff4f 25-May-2016 Manman Ren <manman.ren@gmail.com>

Objective-C Class Properties: Autoupgrade "Class Properties" module flag.

When we have "Image Info Version" module flag but don't have "Class Properties"
module flag, set "Class Properties" module f

Objective-C Class Properties: Autoupgrade "Class Properties" module flag.

When we have "Image Info Version" module flag but don't have "Class Properties"
module flag, set "Class Properties" module flag to 0, so we can correctly emit
errors when one module has the flag set and another module does not.

rdar://26469641

llvm-svn: 270791

show more ...


# 4718f8b5 24-May-2016 Peter Collingbourne <peter@pcc.me.uk>

Add FIXMEs to all derived classes of std::error_category.

This helps make clear that we're moving away from std::error_code.

Differential Revision: http://reviews.llvm.org/D20592

llvm-svn: 270604


# 85338cbd 06-May-2016 Adrian Prantl <aprantl@apple.com>

Implement a safer bitcode upgrade for DISubprogram.

The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized b

Implement a safer bitcode upgrade for DISubprogram.

The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized by the
time the DISubprogram is visited. This assumption may not hold true as future
versions of LLVM may decide to write out bitcode in a different order. This
patch corrects this by introducing a versioning bit next to the distinct flag to
unambiguously differentiate the new from the old record layouts.

Note for people stabilizing LLVM out-of-tree: This patch introduces a bitcode
incompatibility with llvm trunk revisions from r266446 — this commit. (But
D19987 will ensure that it degrades gracefully).

http://reviews.llvm.org/D20004
rdar://problem/26074194

llvm-svn: 268816

show more ...


# 9e95da77 05-May-2016 Teresa Johnson <tejohnson@google.com>

[ThinLTO] Remove missed piece of lazy summary reading support (NFC)

Missed in r267097.

llvm-svn: 268597


# 02e98331 27-Apr-2016 Teresa Johnson <tejohnson@google.com>

[ThinLTO] Use valueid instead of bitcode offsets in combined index file

Summary:
With the removal of support for lazy parsing of combined index summary
records (e.g. r267344), we no longer need to i

[ThinLTO] Use valueid instead of bitcode offsets in combined index file

Summary:
With the removal of support for lazy parsing of combined index summary
records (e.g. r267344), we no longer need to include the summary record
bitcode offset in the VST entries for definitions. Change the combined
index format to be similar to the per-module index format in using value
ids to cross-reference from the summary record to the VST entry (rather
than the summary record bitcode offset to cross-reference in the other
direction).

The visible changes are:
1) Add the value id to the combined summary records
2) Remove the summary offset from the combined VST records, which has
the following effects:
- No longer need the VST_CODE_COMBINED_GVDEFENTRY record, as all
combined index VST entries now only contain the value id and
corresponding GUID.
- No longer have duplicate VST entries in the case where there are
multiple definitions of a symbol (e.g. weak/linkonce), as they all
have the same value id and GUID.

An implication of #2 above is that in order to hook up an alias to the
correct aliasee based on the value id of the aliasee recorded in the
combined index alias record, we need to scan the entries in the index
for that GUID to find the one from the same module (i.e. the case where
there are multiple entries for the aliasee). But the reader no longer
has to maintain a special map to hook up the alias/aliasee.

Reviewers: joker.eph

Subscribers: joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D19481

llvm-svn: 267712

show more ...


# 03a04a58 24-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

BitcodeReader: Delay metadata parsing until reading a function body

There's hardly any functionality change here. Instead of calling
materializeMetadata on the first call to materialize(GlobalValue

BitcodeReader: Delay metadata parsing until reading a function body

There's hardly any functionality change here. Instead of calling
materializeMetadata on the first call to materialize(GlobalValue*), wait
until the first one that's actually going to do something. Noticed by
inspection; I don't have a concrete case where this makes a difference.

Added an assertion in materializeMetadata to be sure this (or a future
change) doesn't delay materializeMetadata after function-level metadata.

llvm-svn: 267345

show more ...


# 28e457bc 24-Apr-2016 Teresa Johnson <tejohnson@google.com>

[ThinLTO] Remove GlobalValueInfo class from index

Summary:
Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly
reference summary objects. The info structure was there to support

[ThinLTO] Remove GlobalValueInfo class from index

Summary:
Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly
reference summary objects. The info structure was there to support lazy
parsing of the combined index summary objects, which is no longer
needed and not supported.

Reviewers: joker.eph

Subscribers: joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D19462

llvm-svn: 267344

show more ...


# 5892c6b9 24-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

BitcodeReader: Fix some holes in upgrade from r267296

Add tests for some missing cases to bitcode upgrade in r267296.

- DICompositeType with an 'elements:' field, which will cause it to be
in

BitcodeReader: Fix some holes in upgrade from r267296

Add tests for some missing cases to bitcode upgrade in r267296.

- DICompositeType with an 'elements:' field, which will cause it to be
involved in a cycle after the upgrade.

- A DIDerivedType that references a class in 'extraData:'.

I updated test/Bitcode/dityperefs-3.8.ll with the missing cases and
regenerated test/Bitcode/dityperefs-3.8.ll.bc.

llvm-svn: 267332

show more ...


# ca2c54e0 24-Apr-2016 Mehdi Amini <mehdi.amini@apple.com>

Add "hasSection" flag in the Summary

Reviewers: tejohnson

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D19405

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267329


# c3ed48c1 24-Apr-2016 Mehdi Amini <mehdi.amini@apple.com>

Reorganize GlobalValueSummary with a "Flags" bitfield.

Right now it only contains the LinkageType, but will be extended
with "hasSection", "isOptSize", "hasInlineAssembly", etc.

Differential Revisi

Reorganize GlobalValueSummary with a "Flags" bitfield.

Right now it only contains the LinkageType, but will be extended
with "hasSection", "isOptSize", "hasInlineAssembly", etc.

Differential Revision: http://reviews.llvm.org/D19404

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267319

show more ...


# 8fe6936e 24-Apr-2016 Mehdi Amini <mehdi.amini@apple.com>

Add a version field in the bitcode for the summary

Differential Revision: http://reviews.llvm.org/D19456

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267318


# ae64eafd 23-Apr-2016 Mehdi Amini <mehdi.amini@apple.com>

Store and emit original name in combined index

Summary:
As discussed in D18298, some local globals can't
be renamed/promoted (because they have a section, or because
they are referenced from inline

Store and emit original name in combined index

Summary:
As discussed in D18298, some local globals can't
be renamed/promoted (because they have a section, or because
they are referenced from inline assembly).
To be able to detect naming collision, we need to keep around
the "GUID" using their original name without taking the linkage
into account.

Reviewers: tejohnson

Subscribers: joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D19454

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267304

show more ...


# 69bdc8af 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

BitcodeReader: Avoid std::vector with non-movable types from r267296

r267298 didn't quite fix the build errors. Use SmallVector instead of
std::vector, the latter of which I think is trying to main

BitcodeReader: Avoid std::vector with non-movable types from r267296

r267298 didn't quite fix the build errors. Use SmallVector instead of
std::vector, the latter of which I think is trying to maintain a strong
exception safety guarantee.

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6228

llvm-svn: 267299

show more ...


# ece57ddd 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

BitcodeReader: Avoid non-moving std::piecewise_construct from r267296

Not exactly sure why the host tries to use a copy constructor here, but
it's easy enough to work around it.

http://lab.llvm.org

BitcodeReader: Avoid non-moving std::piecewise_construct from r267296

Not exactly sure why the host tries to use a copy constructor here, but
it's easy enough to work around it.

http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11/builds/6227

llvm-svn: 267298

show more ...


# a59d3e5a 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

DebugInfo: Remove MDString-based type references

Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*. It is no longer legal to refer to a DICompositeType by its
'identifi

DebugInfo: Remove MDString-based type references

Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*. It is no longer legal to refer to a DICompositeType by its
'identifier:', and DIBuilder no longer retains all types with an
'identifier:' automatically.

Aside from the bitcode upgrade, this is mainly removing logic to resolve
an MDString-based reference to an actualy DIType. The commits leading
up to this have made the implicit type map in DICompileUnit's
'retainedTypes:' field superfluous.

This does not remove DITypeRef, DIScopeRef, DINodeRef, and
DITypeRefArray, or stop using them in DI-related metadata. Although as
of this commit they aren't serving a useful purpose, there are patchces
under review to reuse them for CodeView support.

The tests in LLVM were updated with deref-typerefs.sh, which is attached
to the thread "[RFC] Lazy-loading of debug info metadata":

http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html

llvm-svn: 267296

show more ...


# 498b4977 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Avoid MSVC failure with default arguments in lambdas from r267270

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11700

llvm-svn: 267277


# e9f85c48 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Avoid ternery statement to please g++ after r267270, NFC

http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36074

llvm-svn: 267272


# 4b1bc647 23-Apr-2016 Duncan P. N. Exon Smith <dexonsmith@apple.com>

BitcodeReader: Avoid referencing unresolved nodes from distinct ones

Each reference to an unresolved MDNode is expensive, since the RAUW
support in MDNode uses a separate allocation and side map. S

BitcodeReader: Avoid referencing unresolved nodes from distinct ones

Each reference to an unresolved MDNode is expensive, since the RAUW
support in MDNode uses a separate allocation and side map. Since
a distinct MDNode doesn't require its operands on creation (unlike
uniuqed nodes, there's no need to check for structural equivalence),
use nullptr for any of its unresolved operands. Besides reducing the
burden on MDNode maps, this can avoid allocating temporary MDNodes in
the first place.

We need some way to track operands. Invent DistinctMDOperandPlaceholder
for this purpose, which is a Metadata subclass that holds an ID and
points at its single user. DistinctMDOperandPlaceholder::replaceUseWith
is just like RAUW, but its name highlights that there is only ever
exactly one use.

There is no support for moving (or, obviously, copying) these. Move
support would be possible but expensive; leaving it unimplemented
prevents user error. In the BitcodeReader I originally considered
allocating on a BumpPtrAllocator and keeping a vector of pointers to
them, and then I realized that std::deque implements exactly this.

A couple of obvious follow-ups:

- Change ValueEnumerator to emit distinct nodes first to take more
advantage of this optimization. (How convenient... I think I might
have a couple of patches for this.)

- Change DIBuilder and its consumers (like CGDebugInfo in clang) to
use something like this when constructing debug info in the first
place.

llvm-svn: 267270

show more ...


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