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 ...

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

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

No functionality change intended, maybe a tiny performance improvement.

llvm-svn: 270997

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 ...

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

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 ...

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

Missed in r267097.

llvm-svn: 268597

[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 ...

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 ...

[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 ...

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 ...

Add "hasSection" flag in the Summary

Reviewers: tejohnson

Subscribers: llvm-commits

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

From: Mehdi Amini <[email protected]>
llvm-svn: 267329

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 <[email protected]>
llvm-svn: 267319

show more ...

Add a version field in the bitcode for the summary

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

From: Mehdi Amini <[email protected]>
llvm-svn: 267318

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 <[email protected]>
llvm-svn: 267304

show more ...

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 ...

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 ...

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 ...

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

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

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

llvm-svn: 267272

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 ...

BitcodeReader: Consistently use IsDistinct, NFC

Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT. This change has NFC, but prepares for using IsDistinct
to optimi

BitcodeReader: Consistently use IsDistinct, NFC

Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT. This change has NFC, but prepares for using IsDistinct
to optimize the behaviour of the getMD() and getMDOrNull() helpers.

llvm-svn: 267268

show more ...

BitcodeReader: Use getMD/getMDOrNull helpers consistently, almost NFC

The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) tha

BitcodeReader: Use getMD/getMDOrNull helpers consistently, almost NFC

The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) that is
already caught by Verifier::visitDILocation. The Verifier is a better
place for this anyway, and being inconsistent with other subclasses of
MDNode isn't serving anyone.

llvm-svn: 267267

show more ...

[ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)

This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to b

[ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)

This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to be needed
since we are moving to a model where the full index is only being
traversed in the thin link step, instead of the back ends.

(The second part of this that I plan to do next is remove the
GlobalValueInfo from the ModuleSummaryIndex - it was mostly needed to
support lazy parsing of summaries. The index can instead reference the
summary structures directly.)

llvm-svn: 267097

show more ...

IR: Use SmallVector instead of std::vector of TrackingMDRef

Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations

IR: Use SmallVector instead of std::vector of TrackingMDRef

Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations
instead of moving them. Found this when I was temporarily deleting the
copy constructor for TrackingMDRef to investigate a performance
bottleneck.

llvm-svn: 266909

show more ...