summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer
Commit message (Collapse)AuthorAgeFilesLines
...
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner2016-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-0/+2
| | | | | | | | | | 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
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-313-19/+43
| | | | | | | | | | 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
* Avoid temporary vector for sorting in BitcodeWriterMehdi Amini2016-05-161-13/+10
| | | | | | | As suggested by Duncan, fixup for r269634 and r269635 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269715
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+8
| | | | | | | | Calls are initialized from a DenseMap. We can sort them using the value id to recover some determinism during serialization. From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 269638
* Revert "ThinLTO: fix non-determinism in bitcode writing"Mehdi Amini2016-05-161-7/+1
| | | | | | | This reverts commit r269634, bots are broken. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269637
* ThinLTO: fix another non-determinism in bitcode writingMehdi Amini2016-05-161-2/+9
| | | | | | | | GlobalVars Refs are initialized from a DenseSet. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269635
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+7
| | | | | | | | Calls are initialized from a DenseMap. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269634
* ThinLTO: fix non-determinism in bitcode writingMehdi Amini2016-05-161-1/+7
| | | | | | | | Refs are initialized from a DenseSet. We can sort them using the value id to recover some determinism during serialization. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269629
* Move helper classes into anonymous namespaces. NFC.Benjamin Kramer2016-05-151-0/+2
| | | | llvm-svn: 269591
* [ThinLTO] Fix Windows debug failure in new iteratorTeresa Johnson2016-05-111-2/+13
| | | | | | | | | | | | This fixes a debug assert on Windows from the new iterator implementation added in r269059. The Windows std::vector iterator operator== checks in debug mode that the containers being iterated over are the same, which they may not be. Fixed by checking that we are iterating over the same container before comparing the container iterators. llvm-svn: 269232
* Restore "[ThinLTO] Emit individual index files for distributed backends"Teresa Johnson2016-05-101-71/+215
| | | | | | | | | | | | | | | | | | | This restores commit r268627: Summary: When launching ThinLTO backends in a distributed build (currently supported in gold via the thinlto-index-only plugin option), emit an individual index file for each backend process as described here: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html ... Differential Revision: http://reviews.llvm.org/D19556 Address msan failures by avoiding std::prev on map.end(), the theory is that this is causing issues due to some known UB problems in __tree. llvm-svn: 269059
* Implement a safer bitcode upgrade for DISubprogram.Adrian Prantl2016-05-061-1/+2
| | | | | | | | | | | | | | | | | | 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
* BitcodeWriter: Simplify. NFC.Peter Collingbourne2016-05-061-4/+2
| | | | llvm-svn: 268707
* Revert "[ThinLTO] Emit individual index files for distributed backends"Vitaly Buka2016-05-051-209/+71
| | | | | | | | | MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52. llvm-svn: 268660
* [ThinLTO] Emit individual index files for distributed backendsTeresa Johnson2016-05-051-71/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When launching ThinLTO backends in a distributed build (currently supported in gold via the thinlto-index-only plugin option), emit an individual index file for each backend process as described here: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html The individual index file encodes the summary and module information required for implementing the importing/exporting decisions made for a given module in the thin link step. This is in place of the current mechanism that uses the combined index to make importing decisions in each back end independently. It is an enabler for doing global summary based optimizations in the thin link step (which will be recorded in the individual index files), and reduces the size of the index that must be sent to each backend process, and the amount of work to scan it in the backends. Rather than create entirely new ModuleSummaryIndex structures (and all the included unique_ptrs) for each backend index file, a map is created to record all of the GUID and summary pointers needed for a particular index file. The IndexBitcodeWriter walks this map instead of the full index (hiding the details of managing the appropriate summary iteration in a new iterator subclass). This is more efficient than walking the entire combined index and filtering out just the needed summaries during each backend bitcode index write. Depends on D19481. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D19556 llvm-svn: 268627
* Clean up to avoid compiler warnings for casting away const qualifiers.Sjoerd Meijer2016-04-271-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D19598 llvm-svn: 267753
* [ThinLTO] Use valueid instead of bitcode offsets in combined index fileTeresa Johnson2016-04-271-61/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ThinLTO] Remove GlobalValueInfo class from indexTeresa Johnson2016-04-241-38/+39
| | | | | | | | | | | | | | | | 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
* Silence two C4806 warnings ('|': unsafe operation: no value of type 'bool' ↵Aaron Ballman2016-04-241-2/+2
| | | | | | promoted to type 'const unsigned int' can equal the given constant). The fact that they trigger with this code seems like it may be a bug, but the warning itself is still generally useful enough to retain it for now. llvm-svn: 267337
* Add "hasSection" flag in the SummaryMehdi Amini2016-04-241-2/+8
| | | | | | | | | | | Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19405 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267329
* Reorganize GlobalValueSummary with a "Flags" bitfield.Mehdi Amini2016-04-241-15/+23
| | | | | | | | | | 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
* Add a version field in the bitcode for the summaryMehdi Amini2016-04-241-0/+8
| | | | | | | Differential Revision: http://reviews.llvm.org/D19456 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 267318
* Store and emit original name in combined indexMehdi Amini2016-04-231-0/+14
| | | | | | | | | | | | | | | | | | | 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
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
* BitcodeWriter: Emit uniqued subgraphs after all distinct nodesDuncan P. N. Exon Smith2016-04-232-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since forward references for uniqued node operands are expensive (and those for distinct node operands are cheap due to DistinctMDOperandPlaceholder), minimize forward references in uniqued node operands. Moreover, guarantee that when a cycle is broken by a distinct node, none of the uniqued nodes have any forward references. In ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs first, delaying distinct nodes until all uniqued nodes have been handled. This guarantees that uniqued nodes only have forward references when there is a uniquing cycle (since r267276 changed ValueEnumerator::organizeMetadata to partition distinct nodes in front of uniqued nodes as a post-pass). Note that a single uniqued subgraph can hit multiple distinct nodes at its leaves. Ideally these would themselves be emitted in post-order, but this commit doesn't attempt that; I think it requires an extra pass through the edges, which I'm not convinced is worth it (since DistinctMDOperandPlaceholder makes forward references quite cheap between distinct nodes). I've added two testcases: - test/Bitcode/mdnodes-distinct-in-post-order.ll is just like test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes instead of uniqued ones. This confirms that, in the absence of uniqued nodes, distinct nodes are still emitted in post-order. - test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal example where a naive post-order traversal would cause one uniqued node to forward-reference another. IOW, it's the motivating test. llvm-svn: 267278
* BitcodeWriter: Emit distinct nodes before uniqued nodesDuncan P. N. Exon Smith2016-04-231-6/+18
| | | | | | | | | | | | | | | When an operand of a distinct node hasn't been read yet, the reader can use a DistinctMDOperandPlaceholder. This is much cheaper than forward referencing from a uniqued node. Change ValueEnumerator::organizeMetadata to partition distinct nodes and uniqued nodes to reduce the overhead of cycles broken by distinct nodes. Mehdi measured this for me; this removes most of the RAUW from the importing step of -flto=thin, even after a WIP patch that removes string-based DITypeRefs (introducing many more cycles to the metadata graph). llvm-svn: 267276
* Address comments.Teresa Johnson2016-04-231-243/+238
| | | | llvm-svn: 267274
* Refactor bitcode writer into classes (NFC)Teresa Johnson2016-04-231-681/+823
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in on the mailing list yesterday, I have refactored BitcodeWriter.cpp to use classes to manage the bitcode writing process, instead of passing around long lists of parameters between static functions. See: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098610.html I created a parent BitcodeWriter class to own the BitstreamWriter, write the header, and contain the main entry point into the writing process. There are two derived classes, one for writing a module and one for writing a combined index file (for ThinLTO), which manage the writing process specific to those bitcode file types. I also changed the functions to conform to LLVM coding standards (lowercase function name first letter). The only two routines that still start with an uppercase letter are the two external interfaces, which can be fixed as a follow-on (I wanted to keep this round just within BitcodeWriter.cpp). Reviewers: dexonsmith, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19447 llvm-svn: 267273
* ValueEnumerator: Use std::find_if, NFCDuncan P. N. Exon Smith2016-04-232-23/+8
| | | | | | | | Mehdi's pattern recognition pulled this one out. This is cleaner with std::find_if than with the strange helper function that took an iterator by reference and updated it. llvm-svn: 267271
* ValueMapper/Enumerator: Clean up code in post-order traversals, NFCDuncan P. N. Exon Smith2016-04-222-25/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-layer the functions in the new (i.e., newly correct) post-order traversals in ValueEnumerator (r266947) and ValueMapper (r266949). Instead of adding a node to the worklist in a helper function and returning a flag to say what happened, return the node itself. This makes the code way cleaner: the worklist is local to the main function, there is no flag for an early loop exit (since we can cleanly bury the loop), and it's perfectly clear when pointers into the worklist might be invalidated. I'm fixing both algorithms in the same commit to avoid repeating the commit message; if you take the time to understand one the other should be easy. The diff itself isn't entirely obvious since the traversals have some noise (i.e., things to do), but here's the high-level change: auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) { => while (I != E) { if (shouldVisit(Op)) { T *Op = *I++; WL.push(Op, Op->begin()); if (shouldVisit(Op)) { return true; return Op; } } return false; return nullptr; }; }; => WL.push(S, S->begin()); WL.push(S, S->begin()); while (!empty()) { while (!empty()) { auto *N = WL.top().N; auto *N = WL.top().N; auto *&I = WL.top().I; auto *&I = WL.top().I; bool DidChange = false; while (I != N->end()) if (helper(*I++)) { => if (T *Op = helper(I, N->end()) { DidChange = true; WL.push(Op, Op->begin()); break; continue; } } if (DidChange) continue; POT.push(WL.pop()); => POT.push(WL.pop()); } } Thanks to Mehdi for helping me find a better way to layer this. llvm-svn: 267099
* BitcodeWriter: Emit metadata in post-order (again)Duncan P. N. Exon Smith2016-04-212-17/+24
| | | | | | | | | | | | | | | Emit metadata nodes in post-order. The iterative algorithm from r266709 failed to maintain this property. After understanding my mistake, it wasn't too hard to write a test with llvm-bcanalyzer (and I've actually made this change once before: see r220340). This also reverts the "noisy" testcase change from r266709. That should have been more of a red flag :/. Note: The same bug crept into the ValueMapper in r265456. I'm still working on the fix. llvm-svn: 266947
* [ThinLTO] Prevent importing of "llvm.used" valuesTeresa Johnson2016-04-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch prevents importing from (and therefore exporting from) any module with a "llvm.used" local value. Local values need to be promoted and renamed when importing, and their presense on the llvm.used variable indicates that there are opaque uses that won't see the rename. One such example is a use in inline assembly. See also the discussion at: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098047.html As part of this, move collectUsedGlobalVariables out of Transforms/Utils and into IR/Module so that it can be used more widely. There are several other places in LLVM that used copies of this code that can be cleaned up as a follow on NFC patch. Reviewers: joker.eph Subscribers: pcc, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18986 llvm-svn: 266877
* BitcodeWriter: Break recursion when enumerating Metadata, almost NFCDuncan P. N. Exon Smith2016-04-192-71/+74
| | | | | | | | | | | Use a worklist instead of recursing through MDNode operands in ValueEnumerator. The actual record output order has changed slightly, but otherwise there's no functionality change. I had to update test/Bitcode/metadata-function-blocks.ll. I renumbered nodes so they continue to match the implicit record ids. llvm-svn: 266709
* [NFC] Header cleanupMehdi Amini2016-04-182-3/+1
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* BitcodeWriter: WorkList => Worklist, NFCDuncan P. N. Exon Smith2016-04-181-5/+5
| | | | | | | | I have no idea how I chose two different spellings in the space of a couple of weeks, but now I can't remember what to use where. Choose "Worklist". llvm-svn: 266582
* ThinLTO: Make aliases explicit in the summaryMehdi Amini2016-04-161-3/+67
| | | | | | | | | | | To be able to work accurately on the reference graph when taking decision about internalizing, promoting, renaming, etc. We need to have the alias information explicit. Differential Revision: http://reviews.llvm.org/D18836 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266517
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Revert "Make aliases explicit in the summary"Mehdi Amini2016-04-131-67/+3
| | | | | | | | | Inadvertently commited... This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266215
* Make aliases explicit in the summaryMehdi Amini2016-04-131-3/+67
| | | | | | | | | | | | | | | | Summary: To be able to work accurately on the reference graph when taking decision about internalizing, promoting, renaming, etc. We need to have the alias information explicit. Reviewers: tejohnson Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18836 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266214
* Add the allocsize attribute to LLVM.George Burgess IV2016-04-121-0/+2
| | | | | | | | | | | | | | | | `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
* [ThinLTO] BitcodeWriter still requires Analysis libraryTeresa Johnson2016-04-111-1/+1
| | | | | | | | | | | This should fix bot failure: http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/9873 The bitcode writer unfortunately still needs the Analysis library, as it replaces old dependence on BFI etc with dependence on new ModuleSummaryAnalysis pass. llvm-svn: 265945
* [ThinLTO] Move summary computation from BitcodeWriter to new passTeresa Johnson2016-04-113-157/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first step in also serializing the index out to LLVM assembly. The per-module summary written to bitcode is moved out of the bitcode writer and to a new analysis pass (ModuleSummaryIndexWrapperPass). The pass itself uses a new builder class to compute index, and the builder class is used directly in places where we don't have a pass manager (e.g. llvm-as). Because we are computing summaries outside of the bitcode writer, we no longer can use value ids created by the bitcode writer's ValueEnumerator. This required changing the reference graph edge type to use a new ValueInfo class holding a union between a GUID (combined index) and Value* (permodule index). The Value* are converted to the appropriate value ID during bitcode writing. Also, this enables removal of the BitWriter library's dependence on the Analysis library that was previously required for the summary computation. Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18763 llvm-svn: 265941
* Plumb the option to emit the `ModuleHash` in the bitcode through the bitcode ↵Mehdi Amini2016-04-101-6/+7
| | | | | | | writer APIs From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265907
* Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC)Mehdi Amini2016-04-071-4/+4
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265729
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-072-0/+29
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith2016-04-051-2/+1
| | | | | | | | | | | | Add a common parent class for ConstantArray, ConstantVector, and ConstantStruct called ConstantAggregate. These are the aggregate subclasses of Constant that take operands. This is mainly a cleanup, adding common `isa` target and removing duplicated code. However, it also simplifies caching which constants point transitively at `GlobalValue` (a possible future direction). llvm-svn: 265466
* Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC)Mehdi Amini2016-04-021-21/+23
| | | | | | | | The index used to contain only Function, but now contains GlobalValue in general. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265230
OpenPOWER on IntegriCloud