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