summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker/LinkModules.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't copy information from aliasee to alias.Rafael Espindola2015-12-021-6/+1
| | | | | | They are independent. llvm-svn: 254541
* Fix linking when we copy over only a decl.Rafael Espindola2015-12-021-22/+34
| | | | | | | We were failing to copy the fact that the GV is weak and in the case of an alias, producing invalid IR. llvm-svn: 254538
* Change ModuleLinker to take a set of GlobalValues to import instead of a ↵Mehdi Amini2015-12-021-5/+5
| | | | | | | | | | | | single one For efficiency reason, when importing multiple functions for the same Module, we can avoid reparsing it every time. Differential Revision: http://reviews.llvm.org/D15102 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 254486
* Use default member initializers.Rafael Espindola2015-12-011-4/+3
| | | | llvm-svn: 254473
* Remove unnecessary getter.Rafael Espindola2015-12-011-4/+1
| | | | llvm-svn: 254466
* Pass down the dst GV to linkGlobalValueBody. NFC.Rafael Espindola2015-12-011-9/+7
| | | | llvm-svn: 254465
* Delete unused includes.Rafael Espindola2015-12-011-9/+0
| | | | llvm-svn: 254457
* clang-format LinkModules.cpp.Rafael Espindola2015-12-011-19/+19
| | | | | | | Most of the file has been changed recently and was already clang-format clean. llvm-svn: 254454
* Use references now that it is natural to do so.Rafael Espindola2015-12-011-77/+72
| | | | | | | The linker never takes ownership of a module or changes which module it is refering to, making it natural to use references. llvm-svn: 254449
* Delete dead code.Rafael Espindola2015-12-011-5/+0
| | | | llvm-svn: 254436
* Use a forwarding constructor instead of an init method.Rafael Espindola2015-12-011-10/+5
| | | | llvm-svn: 254435
* Delete the setModule method from the Linker.Rafael Espindola2015-12-011-4/+0
| | | | | | | | | | | It was only used from LTO for a debug feature, and LTO can just create another linker. It is pretty odd to have a method to reset the module in the middle of a link. It would make IdentifiedStructTypes inconsistent with the Module for example. llvm-svn: 254434
* Make appending var linking less of a special case.Rafael Espindola2015-12-011-75/+36
| | | | | | | | | | | | | | | | | | It has to be a bit special because: * materializeInitFor is not really supposed to call replaceAllUsesWith. The caller has a plain variable with Dst and expects just the initializer to be set, not for it to be removed. * Calling mutateType as we used to do before gets some type inconsistency which breaks the bitcode writer. * If linkAppendingVarProto create a dest decl with the correct type to avoid the above problems, it needs to put the original dst init in some side table for materializeInitFor to use. In the end the simplest solution seems to be to just have linkAppendingVarProto do all the work and set ValueMap[SrcGV to avoid recursion. llvm-svn: 254424
* Bring r254336 back:Rafael Espindola2015-12-011-77/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The difference is that now we don't error on out-of-comdat access to internal global values. We copy them instead. This seems to match the expectation of COFF linkers (see pr25686). Original message: Start deciding earlier what to link. A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254418
* This reverts commit r254336 and r254344.Rafael Espindola2015-11-301-76/+77
| | | | | | They broke a bot and I am debugging why. llvm-svn: 254347
* Disable a consistency check.Rafael Espindola2015-11-301-5/+1
| | | | | | Trying to figure out why it fails on a bot but passes locally. llvm-svn: 254344
* Start deciding earlier what to link.Rafael Espindola2015-11-301-77/+80
| | | | | | | | | | | | | | | | | | | | | | A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254336
* Fix another llvm.ctors merging bug.Rafael Espindola2015-11-301-2/+3
| | | | | | | We were not looking past casts to see if an element should be included or not. llvm-svn: 254313
* Simplify. NFC.Rafael Espindola2015-11-291-16/+12
| | | | llvm-svn: 254254
* Correctly handle llvm.global_ctors merging.Rafael Espindola2015-11-291-42/+48
| | | | | | | We were not handling the case where an entry must be dropped and the destination module has no llvm.global_ctors. llvm-svn: 254241
* Fix a crash when writing merged bitcode.Rafael Espindola2015-11-291-5/+14
| | | | | | | Playing with mutateType in here was making getValueType and getType incompatible. llvm-svn: 254240
* Simplify the linking of recursive data.Rafael Espindola2015-11-271-39/+35
| | | | | | | | Now the ValueMapper has two callbacks. The first one maps the declaration. The ValueMapper records the mapping and then materializes the body/initializer. llvm-svn: 254209
* Disallow aliases to available_externally.Rafael Espindola2015-11-261-1/+4
| | | | | | | | | | | | They are as much trouble as aliases to declarations. They are requiring the code generator to define a symbol with the same value as another symbol, but the second symbol is undefined. If representing this is important for some optimization, we could add support for available_externally aliases. They would be *required* to point to a declaration (or available_externally definition). llvm-svn: 254170
* [ThinLTO] Handle previously imported and promoted locals in module linkerTeresa Johnson2015-11-241-2/+2
| | | | | | | | | | | The new function import pass exposed an issue when we import references to local values on multiple importing passes. They are renamed on each import pass, and we need to ensure that the already promoted and renamed references existing in the dest module are correctly identified and updated so that they aren't spuriously renamed again (due to a perceived conflict with the newly linked reference). llvm-svn: 254009
* Add const qualifier for FunctionInfoIndex in ModuleLinker and linkInModule() ↵Mehdi Amini2015-11-231-3/+4
| | | | | | | (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 253840
* Replace dyn_cast with isa in places that weren't using the returned value ↵Craig Topper2015-11-181-1/+1
| | | | | | for more than a boolean check. NFC. llvm-svn: 253441
* Fix mapping of unmaterialized global values during metadata linkingTeresa Johnson2015-11-151-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The patch to move metadata linking after global value linking didn't correctly map unmaterialized global values to null as desired. They were in fact mapped to the source copy. It largely worked by accident since most module linker clients destroyed the source module which caused the source GVs to be replaced by null, but caused a failure with LTO linking on Windows: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312869.html The problem is that a null return value from materializeValueFor is handled by mapping the value to self. This is the desired behavior when materializeValueFor is passed a non-GlobalValue. The problem is how to distinguish that case from the case where we really do want to map to null. This patch addresses this by passing in a new flag to the value mapper indicating that unmapped global values should be mapped to null. Other Value types are handled as before. Note that the documented behavior of asserting on unmapped values when the flag RF_IgnoreMissingValues isn't set is currently disabled with FIXME notes due to bootstrap failures. I modified these disabled asserts so when they are eventually enabled again it won't assert for the unmapped values when the new RF_NullMapMissingGlobalValues flag is set. I also considered using a callback into the value materializer, but a flag seemed cleaner given that there are already existing flags. I also considered modifying materializeValueFor to return the input value when we want to map to source and then treat a null return to mean map to null. However, there are other value materializer subclasses that implement materializeValueFor, and they would all need to be audited and the return values possibly changed, which seemed error-prone. Reviewers: dexonsmith, joker.eph Subscribers: pcc, llvm-commits Differential Revision: http://reviews.llvm.org/D14682 llvm-svn: 253170
* [lib/Linker] Convert assert(false) to llvm_unreachable().Davide Italiano2015-11-131-1/+1
| | | | llvm-svn: 253005
* Ensure ModuleLinker materializes complete comdat groupsTeresa Johnson2015-11-101-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The module linker lazy links some "discardable if unused" global values (e.g. linkonce), materializing and linking them only if they are referenced in the module. If a comdat group contains a linkonce member that is not referenced, however, it would not be materialized and linked, leading to an incomplete comdat group. If there are other object files not part of the same LTO link that also define and use that comdat group, the linker may select the incomplete group leading to link time unsats. To solve this, whenever a global value body is linked, make sure we materialize any other members of the same comdat group that are not yet materialized. This ensures they are in the lazy link list and get linked as well. Added new test and adjusted old test to remove parts that didn't make sense with fix. Reviewers: rafael Subscribers: dexonsmith, davidxl, llvm-commits Differential Revision: http://reviews.llvm.org/D14516 llvm-svn: 252647
* [ThinLTO] Update comment per change in WeakAny handling (NFC)Teresa Johnson2015-11-101-1/+3
| | | | llvm-svn: 252627
* [ThinLTO] WeakAny fixes/cleanupTeresa Johnson2015-11-101-17/+18
| | | | | | | | | | | | | | | | | | | | | | | Ensure WeakAny variables are imported as ExternalWeak declarations. To handle WeakAny more consistently and fix this issue: 1) Update helper doImportAsDefinition to properly flag WeakAny variables and aliases as not importing defintions. Update callers of doImportAsDefinition to remove now redundant checks for WeakAny aliases, or ignore aliases, as appropriate. 2) Add any !doImportAsDefinition GVs to DoNotLinkFromSource set during linking of the GV prototype, where we usually add GVs to the DoNotLinkFromSource set for other reasons. Remove now unnecessary adding of WeakAny aliases to DoNotLinkFromSource set from copyGlobalAliasProto. Remove now unnecessary guard against linking non-imported function bodies from ModuleLinker::run. llvm-svn: 252626
* Restore "Move metadata linking after lazy global materialization/linking."Teresa Johnson2015-11-061-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit r251965. Restore "Move metadata linking after lazy global materialization/linking." This restores commit r251926, with fixes for the LTO bootstrapping bot failure. The bot failure was caused by references from debug metadata to otherwise unreferenced globals. Previously, this caused the lazy linking to link in their defs, which is unnecessary. With this patch, because lazy linking is complete when we encounter the metadata reference, the materializer created a declaration. For definitions such as aliases and comdats, it is illegal to have a declaration. Furthermore, metadata linking should not change code generation. Therefore, when linking of global value bodies is complete, the materializer will simply return nullptr as the new reference for the linked metadata. This change required fixing a different test to ensure there was a real reference to a linkonce global that was only being reference from metadata. Note that the new changes to the only-needed-named-metadata.ll test illustrate an issue with llvm-link -only-needed handling of comdat groups, whereby it may result in an incomplete comdat group. I note this in the test comments, but the issue is orthogonal to this patch (it can be reproduced without any metadata at head). Reviewers: dexonsmith, rafael, tra Subscribers: tobiasvk, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D14447 llvm-svn: 252320
* Restore "Move metadata linking after lazy global materialization/linking."Teresa Johnson2015-11-061-9/+9
| | | | | | This reverts commit r251965. llvm-svn: 252319
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-051-50/+0
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
* [ThinLTO] Always set linkage type to external when converting aliasTeresa Johnson2015-11-041-2/+4
| | | | | | | | When converting an alias to a non-alias when the aliasee is not imported, ensure that the linkage type is set to external so that it is a valid linkage type. Added a test case that exposed this issue. llvm-svn: 252054
* Revert "Move metadata linking after lazy global materialization/linking."Teresa Johnson2015-11-031-9/+9
| | | | | | | | | | | This reverts commit r251926. I believe this is causing an LTO bootstrapping bot failure (http://lab.llvm.org:8080/green/job/llvm-stage2-cmake-RgLTO_build/3669/). Haven't been able to repro it yet, but after looking at the metadata I am pretty sure I know what is going on. llvm-svn: 251965
* Move metadata linking after lazy global materialization/linking.Teresa Johnson2015-11-031-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, named metadata is linked before the LazilyLinkGlobalValues list is walked and materialized/linked. As a result, references from DISubprogram and DIGlobalVariable metadata to yet unmaterialized functions and variables cause them to be added to the lazy linking list and their definitions are materialized and linked. This makes the llvm-link -only-needed option not have the intended effect when debug information is present, as the otherwise unneeded functions/variables are still linked in. Additionally, for ThinLTO I have implemented a mechanism to only link in debug metadata needed by imported functions. Moving named metadata linking after lazy GV linking will facilitate applying this mechanism to the LTO and "llvm-link -only-needed" cases as well. Reviewers: dexonsmith, tra, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14195 llvm-svn: 251926
* Restore "Support for ThinLTO function importing and symbol linking."Teresa Johnson2015-11-031-37/+356
| | | | | | | This restores commit r251837, with the new library dependence added to llvm-link/Makefile to address bot failures. llvm-svn: 251866
* Revert "Support for ThinLTO function importing and symbol linking."Teresa Johnson2015-11-021-356/+37
| | | | | | | | | | | | | | | | | | | | This reverts commit r251837, due to a number of bot failures of the form: /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::Module const*, bool)' /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()' I'm not sure why these are happening - I added Object to the requred libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these symbols come out of libLLVMObject.a. What am I missing? llvm-svn: 251841
* Support for ThinLTO function importing and symbol linking.Teresa Johnson2015-11-021-37/+356
| | | | | | | | | | | | | | | | | | | | | Summary: Support for necessary linkage changes and symbol renaming during ThinLTO function importing. Also includes llvm-link support for manually importing functions and associated llvm-link based tests. Note that this does not include support for intelligently importing metadata, which is currently imported duplicate times. That support will be in the follow-on patch, and currently is ignored by the tests. Reviewers: dexonsmith, joker.eph, davidxl Subscribers: tobiasvk, tejohnson, llvm-commits Differential Revision: http://reviews.llvm.org/D13515 llvm-svn: 251837
* Linker: Remove implicit ilist iterator conversion, NFCDuncan P. N. Exon Smith2015-10-191-1/+1
| | | | llvm-svn: 250748
* Fix -Wdeprecated regarding ORC copying ValueMaterializersDavid Blaikie2015-10-191-1/+1
| | | | | | | | | | | | As usual, this is a polymorphic hierarchy without polymorphic ownership, so simply make the dtor protected non-virtual, protected default copy ctor/assign, and make derived classes final. The derived classes will pick up correct default public copy ops (and dtor) implicitly. (wish I could add -Wdeprecated to the build, but last time I tried it triggered on some system headers I still need to look into/figure out) llvm-svn: 250747
* [opaque pointer types] Switch a few cases of getElementType over, since I ↵David Blaikie2015-09-141-2/+2
| | | | | | had them lying around anyway llvm-svn: 247610
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-1/+2
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* New bitcode linker flags:Artem Belevich2015-09-011-13/+33
| | | | | | | | | -only-needed -- link in only symbols needed by destination module -internalize -- internalize linked symbols Differential Revision: http://reviews.llvm.org/D12459 llvm-svn: 246561
* Linker: Remove empty destructor.Peter Collingbourne2015-08-211-3/+0
| | | | llvm-svn: 245672
* Linker: Move distinct MDNodes instead of cloningDuncan P. N. Exon Smith2015-08-031-17/+20
| | | | | | | | | | | | | | | | | | | | | Instead of cloning distinct `MDNode`s when linking in a module, just move them over. The module linker destroys the source module, so the old node would otherwise just be leaked on the context. Create the new node in place. This also reduces the number of cloned uniqued nodes (since it's less likely their operands have changed). This mapping strategy is only correct when we're discarding the source, so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`. There's nothing observable in terms of `llvm-link` output here: the linked module should be semantically identical. I'll be adding more 'distinct' nodes to the debug info metadata graph in order to break uniquing cycles, so the benefits of this will partly come in future commits. However, we should get some gains immediately, since we have a fair number of 'distinct' `DILocation`s being linked in. llvm-svn: 243883
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-2/+2
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Linker: Do not expect comdat to exist in source module.Peter Collingbourne2015-06-221-2/+2
| | | | llvm-svn: 240341
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-2/+2
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
OpenPOWER on IntegriCloud