summaryrefslogtreecommitdiffstats
path: root/llvm/test/Linker
Commit message (Collapse)AuthorAgeFilesLines
...
* Linker: Move special casing for available_externally in IRMover to clients. ↵Peter Collingbourne2017-02-021-0/+2
| | | | | | | | | | NFCI. The goal is to simplify the semantic model for clients of IRMover. Differential Revision: https://reviews.llvm.org/D29435 llvm-svn: 293864
* Renumber testcase metadata nodes after r290153.Adrian Prantl2016-12-224-78/+101
| | | | | | | | | | | | | This patch renumbers the metadata nodes in debug info testcases after https://reviews.llvm.org/D26769. This is a separate patch because it causes so much churn. This was implemented with a python script that pipes the testcases through llvm-as - | llvm-dis - and then goes through the original and new output side-by side to insert all comments at a close-enough location. Differential Revision: https://reviews.llvm.org/D27765 llvm-svn: 290292
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-205-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-165-15/+11
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-165-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-165-15/+11
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-165-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [ThinLTO] Stop importing constant global vars as copies in the backendTeresa Johnson2016-12-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were doing an optimization in the ThinLTO backends of importing constant unnamed_addr globals unconditionally as a local copy (regardless of whether the thin link decided to import them). This should be done in the thin link instead, so that resulting exported references are marked and promoted appropriately, but will need a summary enhancement to mark these variables as constant unnamed_addr. The function import logic during the thin link was trying to handle this proactively, by conservatively marking all values referenced in the initializer lists of exported global variables as also exported. However, this only handled values referenced directly from the initializer list of an exported global variable. If the value is itself a constant unnamed_addr variable, we could end up exporting its references as well. This caused multiple issues. The first is that the transitively exported references weren't promoted. Secondly, some could not be promoted/renamed (e.g. they had a section or other constraint). recursively, instead of just adding the first level of initializer list references to the ExportList directly. Remove this optimization and the associated handling in the function import backend. SPEC measurements indicate we weren't getting much from it in any case. Fixes PR31052. Reviewers: mehdi_amini Subscribers: krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26880 llvm-svn: 288446
* Linker: Remove unnecessary call to copyMetadata in IRLinker::linkGlobalVariable.Peter Collingbourne2016-11-143-4/+76
| | | | | | | | | | | This was causing us to create duplicate metadata on global variables. Debug info test case by Adrian Prantl, additional test cases by me. Fixes PR31012. Differential Revision: https://reviews.llvm.org/D26622 llvm-svn: 286905
* Fix autoupgrade logic for Objective-C class properties module flagMehdi Amini2016-09-162-0/+21
| | | | | | | | | | | | | | Previous we were issuing an error when linking a module containing the new Objective-C metadata structure for class properties with an "old" one. Now instead we downgrade the module flag so that the Objective-C runtime does not expect the new metadata structure. This is consistent with what ld64 is doing on binary files. Differential Revision: https://reviews.llvm.org/D24620 llvm-svn: 281685
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-134-14/+15
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
* IR: Drop uniquing when an MDNode Value operand is deletedDuncan P. N. Exon Smith2016-08-032-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR28697. An MDNode can indirectly refer to a GlobalValue, through a ConstantAsMetadata. When the GlobalValue is deleted, the MDNode operand is reset to `nullptr`. If the node is uniqued, this can lead to a hard-to-detect cache invalidation in a Metadata map that's shared across an LLVMContext. Consider: 1. A map from Metadata* to `T` called RemappedMDs. 2. A node that references a global variable, `!{i1* @GV}`. 3. Insert `!{i1* @GV} -> SomeT` in the map. 4. Delete `@GV`, leaving behind `!{null} -> SomeT`. Looking up the generic and uninteresting `!{null}` gives you `SomeT`, which is likely related to `@GV`. Worse, `SomeT`'s lifetime may be tied to the deleted `@GV`. This occurs in practice in the shared ValueMap used since r266579 in the IRMover. Other code that handles more than one Module (with different lifetimes) in the same LLVMContext could hit it too. The fix here is a partial revert of r225223: in the rare case that an MDNode operand is a ConstantAsMetadata (i.e., wrapping a node from the Value hierarchy), drop uniquing if it gets replaced with `nullptr`. This changes step #4 above to leave behind `distinct !{null} -> SomeT`, which can't be confused with the generic `!{null}`. In theory, this can cause some churn in the LLVMContext's MDNode uniquing map when Values are being deleted. However: - The number of GlobalValues referenced from uniqued MDNodes is expected to be quite small. E.g., the debug info metadata schema only references GlobalValues from distinct nodes. - Other Constants have the lifetime of the LLVMContext, whose teardown is careful to drop references before deleting the constants. As a result, I don't expect a compile time regression from this change. llvm-svn: 277625
* Don't verify inputs to the Linker if ODR merging.Rafael Espindola2016-06-293-1/+27
| | | | | | | | | | | | | | | | | | This fixes pr28072. The point, as Duncan pointed out, is that the file is already partially linked by just reading it. Long term I think the solution is to make metadata owned by the module and then the linker will lazily read it and be in charge of all the linking. Running a verifier in each input will defeat the lazy loading, but will be legal. Right now we are at the unfortunate position that to support odr merging we cannot verify the inputs, which mildly annoying (see test update). llvm-svn: 274148
* Linker: Copy metadata when linking declarations.Peter Collingbourne2016-06-241-0/+19
| | | | | | Differential Revision: http://reviews.llvm.org/D21624 llvm-svn: 273692
* ValueMapper: fix assertion when null-mapping a constant for linking metadataMehdi Amini2016-05-281-0/+11
| | | | | | | | | | | | | | | | Summary: When RF_NullMapMissingGlobalValues is set, mapValue can return null for GlobalValue. When mapping the operands of a constant that is referenced from metadata, we need to handle this case and actually return null instead of mapping this constant. Reviewers: dexonsmith, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D20713 llvm-svn: 271129
* Linker: teach the IR mover to return llvm::Error.Peter Collingbourne2016-05-272-2/+2
| | | | | | | | | This will be needed in order to consistently return an Error to clients of the API being developed in D20268. Differential Revision: http://reviews.llvm.org/D20550 llvm-svn: 270967
* IRLinker: fix double scheduling of mapping a global value because of an aliasMehdi Amini2016-05-251-0/+13
| | | | | | | | | | | | This test was hitting an assertion in the value mapper because the IRLinker was trying to map two times @A while materializing the initializer for @C. Fix http://llvm.org/PR27850 Differential Revision: http://reviews.llvm.org/D20586 llvm-svn: 270757
* Make "@name =" mandatory for globals in .ll files.Rafael Espindola2016-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | An oddity of the .ll syntax is that the "@var = " in @var = global i32 42 is optional. Writing just global i32 42 is equivalent to @0 = global i32 42 This means that there is a pretty big First set at the top level. The current implementation maintains it manually. I was trying to refactor it, but then started wondering why keep it a all. I personally find the above syntax confusing. It looks like something is missing. This patch removes the feature and simplifies the parser. llvm-svn: 269096
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-2312-58/+58
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix recursive -only-needed.Rafael Espindola2016-04-212-0/+19
| | | | | | We were assuming that only linkonce_odr GVs were lazy linked. llvm-svn: 266995
* ThinLTO/ModuleLinker: add a flag to not always pull-in linkonce when ↵Mehdi Amini2016-04-211-1/+1
| | | | | | | | | | | | | | | | | | | performing importing Summary: The function importer already decided what symbols need to be pulled in. Also these magically added ones will not be in the export list for the source module, which can confuse the internalizer for instance. Reviewers: tejohnson, rafael Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19096 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266948
* ThinLTO: never promote as external weakMehdi Amini2016-04-201-1/+1
| | | | | | | | | This linkage is *not* intended to express that a declaration refers to a weak symbol, but that the symbol might not be present at link time. I don't believe it was the intent. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266856
* IR: Enable debug info type ODR uniquing for forward declsDuncan P. N. Exon Smith2016-04-192-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | Add a new method, DICompositeType::buildODRType, that will create or mutate the DICompositeType for a given ODR identifier, and use it in LLParser and BitcodeReader instead of DICompositeType::getODRType. The logic is as follows: - If there's no node, create one with the given arguments. - Else, if the current node is a forward declaration and the new arguments would create a definition, mutate the node to match the new arguments. - Else, return the old node. This adds a missing feature supported by the current DITypeIdentifierMap (which I'm slowly making redudant). The only remaining difference is that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas DICompositeType::buildODRType has a "the-first-one-wins" rule. For now I'm leaving behind DICompositeType::getODRType since it has obvious, low-level semantics that are convenient for unit testing. llvm-svn: 266786
* Linker: Simplify test/Linker/dicompositetype-unique.ll, NFCDuncan P. N. Exon Smith2016-04-191-11/+9
| | | | | | | | | Simplify the test logic a little, sharing logic between the two linking directions by specifying -check-prefix multiple times. Now it's more obvious what's hte same and different between the two directions, and there is less CHECK duplication. This is a prep for expanding the test. llvm-svn: 266773
* ModuleLinker: Do not import linkonce/weak as "external_weak"Mehdi Amini2016-04-191-2/+2
| | | | | | | | | | | | | | | Summary: There is no reason to have a weak reference because the external definition will be weak. Reviewers: rafael Subscribers: llvm-commits, tejohnson Differential Revision: http://reviews.llvm.org/D19267 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266750
* IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFCDuncan P. N. Exon Smith2016-04-191-2/+2
| | | | | | | | | | | | | | Lift the API for debug info ODR type uniquing up a layer. Instead of clients managing the map directly on the LLVMContext, add a static method to DICompositeType called getODRType and handle the map in the background. Also adds DICompositeType::getODRTypeIfExists, so far just for convenience in the unit tests. This simplifies the logic in LLParser and BitcodeReader. Because of argument spam there are actually a few more lines of code now; I'll see if I come up with a reasonable way to clean that up. llvm-svn: 266742
* [DWARF] Force a linkage_name on an inlined subprogram's abstract origin.Paul Robinson2016-04-181-2/+2
| | | | | | | | | | | | | When we suppress linkage names, for a non-inlined subprogram the name can still be found in the object-file symbol table, because we have the code address of the subprogram. This is not necessarily the case for an inlined subprogram, so we still want to emit the linkage name in the DWARF. Put this on the abstract-origin DIE because it's common to all inlined instances. Differential Revision: http://reviews.llvm.org/D18706 llvm-svn: 266692
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-172-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* IR: Use ODR to unique DICompositeType membersDuncan P. N. Exon Smith2016-04-171-0/+4
| | | | | | | | | | | | | | Merge members that are describing the same member of the same ODR type, even if other bits differ. If the file or line differ, we don't care; if anything else differs, it's an ODR violation (and we still don't really care). For DISubprogram declarations, this looks at the LinkageName and Scope. For DW_TAG_member instances of DIDerivedType, this looks at the Name and Scope. In both cases, we know that the Scope follows ODR rules if it has a non-empty identifier. llvm-svn: 266548
* Linker: Clarify test/Linker/type-unique-odr-a.ll, NFCDuncan P. N. Exon Smith2016-04-171-17/+23
| | | | | | | | | | | | | | Split up the long RUN and clarify the CHECK lines: - Explicitly confirm there are no other subprograms inside of "A". - Remove checks for "bar" and "baz", which were just implicitly checking that there were no other subprograms inside of "A". This prepares for adding a RUN line which links the two files in the opposite direction. llvm-svn: 266543
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-1537-174/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move summary creation out of llvm-as into optMehdi Amini2016-04-125-12/+12
| | | | | | | | | | | | | | | | | | Summary: Let keep llvm-as "dumb": it converts textual IR to bitcode. This commit removes the dependency from llvm-as to libLLVMAnalysis. We'll add back summary in llvm-as if we get to a textual representation for it at some point. In the meantime, opt seems like a better place for that. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19032 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266131
* ThinLTO renaming: use module hash instead of position in the summaryMehdi Amini2016-04-111-11/+11
| | | | | | | | | This is more robust to changes in the link ordering. Differential Revision: http://reviews.llvm.org/D18946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266018
* Legalize the debug info in this testcase in anticipation of future Verifier ↵Adrian Prantl2016-04-112-27/+46
| | | | | | improvements. llvm-svn: 266017
* Add missing DICompileUnit to this testcaseAdrian Prantl2016-04-112-0/+8
| | | | llvm-svn: 265995
* More upgrading of old- and very-old-style debug info in testcases.Adrian Prantl2016-04-112-0/+4
| | | | llvm-svn: 265953
* testcase gardening: update the emissionKind enum to the new syntax. (NFC)Adrian Prantl2016-04-0135-35/+35
| | | | llvm-svn: 265081
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-3121-21/+21
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* Upgrade some wildly anachronistic debug info in testcases.Adrian Prantl2016-03-294-8/+2
| | | | llvm-svn: 264797
* Fix another case where we were unconditionally linking linkonce GVs.Rafael Espindola2016-03-242-0/+18
| | | | | | | With this I think that now llvm-link, lld and the gold plugin should agree on which symbol is kept. llvm-svn: 264292
* Fix resolution of linkonce symbols in comdats.Rafael Espindola2016-03-242-0/+15
| | | | | | | | | | | After comdat processing, the symbols still go through regular symbol resolution. We were not doing it for linkonce symbols since they are lazy linked. This fixes pr27044. llvm-svn: 264288
* Fix lazy linking of comdat members.Rafael Espindola2016-03-241-2/+2
| | | | | | | | | | | If not for lazy linking of linkonce GVs, comdats are just a preprocessing before symbol resolution. Lazy linking complicates it since when we pick a visible member of comdat, we have to make sure the rest of it passes symbol resolution too. llvm-svn: 264223
* Fix logic for which symbols to keep with comdats.Rafael Espindola2016-03-233-1/+93
| | | | | | | | | | | | If a comdat is dropped, all symbols in it are dropped. If a comdat is kept, the symbols survive to pass regular symbol resolution. With this patch we do that for all global symbols. The added test is a copy of test/tools/gold/X86/comdat.ll that we now pass. llvm-svn: 264192
* Drop comdats from the dst module if they are not selected.Rafael Espindola2016-03-222-0/+38
| | | | | | | | | | | | | | | | | | | | | | | A really unfortunate design of llvm-link and related libraries is that they operate one module at a time. This means they can copy a GV to the destination module that should not be there in the final result because a later bitcode file takes precedence. We already handled cases like a strong GV replacing a weak for example. One case that is not currently handled is a comdat replacing another. This doesn't happen in ELF, but with COFF largest selection kind it is possible. In "llvm-link a.ll b.ll" if the selected comdat was from a.ll, everything will work and we will not copy the comdat from b.ll. But if we run "llvm-link b.ll a.ll", we fail to delete the already copied comdat from b.ll. This patch fixes that. llvm-svn: 264103
* Rework linkInModule(), making it oblivious to ThinLTOMehdi Amini2016-03-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: ThinLTO is relying on linkInModule to import selected function. However a lot of "magic" was hidden in linkInModule and the IRMover, who would rename and promote global variables on the fly. This is moving to an approach where the steps are decoupled and the client is reponsible to specify the list of globals to import. As a consequence some test are changed because they were relying on the previous behavior which was importing the definition of *every* single global without control on the client side. Now the burden is on the client to decide if a global has to be imported or not. Reviewers: tejohnson Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18122 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263863
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-155-28/+28
| | | | | | | | | | | | | | | (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
* Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson2016-03-145-28/+28
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-145-28/+28
| | | | | | | | | | | | | 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
* [ThinLTO] Remove imported available externally defs from comdats.Teresa Johnson2016-02-082-0/+32
| | | | | | | | | | | | | | | Summary: Available externally definitions are considered declarations for the linker and eventually dropped. As such they are not allowed to be in comdats. Remove any such imported functions from comdats. Reviewers: rafael Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D16120 llvm-svn: 260122
* Add a test for r258362.Rafael Espindola2016-02-012-0/+25
| | | | | | Thanks to Mehdi for finding it. llvm-svn: 259394
OpenPOWER on IntegriCloud