summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker/LinkModules.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-151-1/+2
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Linker] PR33527 - Linker::LinkOnlyNeeded should import AppendingLinkage globalsBenoit Belley2017-08-091-2/+12
| | | | | | | | | | | Linker::LinkOnlyNeeded should always import globals with AppendingLinkage. This resolves PR33527. Differential Revision: https://reviews.llvm.org/D34448 llvm-svn: 310522
* [Linker] Provide callback for internalizationJonas Devlieghere2017-03-131-19/+27
| | | | | | Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
* IRMover: Merge flags LinkModuleInlineAsm and IsPerformingImport.Peter Collingbourne2017-02-031-1/+0
| | | | | | | | | Currently these flags are always the inverse of each other, so there is no need to keep them separate. Differential Revision: https://reviews.llvm.org/D29471 llvm-svn: 294016
* ModuleLinker: Remove importing support. NFCI.Peter Collingbourne2017-02-031-58/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D29470 llvm-svn: 294015
* FunctionImport: Use IRMover directly.Peter Collingbourne2017-02-031-2/+1
| | | | | | | | | | | | The importer was previously using ModuleLinker in a sort of "IRMover mode". Use IRMover directly instead in order to remove a level of indirection. I will remove all importing support from ModuleLinker in a separate change. Differential Revision: https://reviews.llvm.org/D29468 llvm-svn: 294014
* Linker: Move special casing for available_externally in IRMover to clients. ↵Peter Collingbourne2017-02-021-1/+2
| | | | | | | | | | NFCI. The goal is to simplify the semantic model for clients of IRMover. Differential Revision: https://reviews.llvm.org/D29435 llvm-svn: 293864
* [ThinLTO] Import only necessary DICompileUnit fieldsTeresa Johnson2016-12-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on mailing list, for ThinLTO importing we don't need to import all the fields of the DICompileUnit. Don't import enums, macros, retained types lists. Also only import local scoped imported entities. Since we don't currently import any global variables, we also don't need to import the list of global variables (added an assert to verify none are being imported). This is being done by pre-populating the value map entries to map the unneeded metadata to nullptr. For the imported entities, we can simply replace the source module's list with a new list containing only those needed imported entities. This is done in the IRLinker constructor so that value mapping automatically does the desired mapping. Reviewers: mehdi_amini, dexonsmith, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27635 llvm-svn: 289441
* [ThinLTO] Don't link module level assembly when importingTeresa Johnson2016-10-121-1/+2
| | | | | | | | | | | | | | | | | | | | | Module inline asm was always being linked/concatenated when running the IRLinker. This is correct for full LTO but not when we are importing for ThinLTO, as it can result in multiply defined symbols when the module asm defines a global symbol. In order to test with llvm-lto2, I had to work around PR30396, where a symbol that is defined in module assembly but defined in the LLVM IR appears twice. Added workaround to llvm-lto2 with a FIXME. Fixes PR30610. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25359 llvm-svn: 284030
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+2
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* Linker: teach the IR mover to return llvm::Error.Peter Collingbourne2016-05-271-4/+15
| | | | | | | | | 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
* Fix recursive -only-needed.Rafael Espindola2016-04-211-1/+1
| | | | | | 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-0/+9
| | | | | | | | | | | | | | | | | | | 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
* ModuleLinker: only import what is in GlobalsToImport, regarless if it is a ↵Mehdi Amini2016-04-201-22/+6
| | | | | | | | | | | | | | | function or not. The alias handling was specific to the old iterative inlining mechanism, so that is dead now. The variable handling could make a difference, since we were previously falling through to the normal selection logic, but we don't observe changes in the validation because no client seems to rely on it. Differential Revision: http://reviews.llvm.org/D19307 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266893
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-291-25/+5
| | | | | | | | | | | Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there is no longer a need to link metadata as a postpass, and all users have been removed. This essentially reverts r255909 and follow-on fixes. llvm-svn: 264763
* Fix another case where we were unconditionally linking linkonce GVs.Rafael Espindola2016-03-241-0/+6
| | | | | | | 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-241-2/+8
| | | | | | | | | | | 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-13/+15
| | | | | | | | | | | 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-231-4/+4
| | | | | | | | | | | | 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-221-1/+72
| | | | | | | | | | | | | | | | | | | | | | | 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-47/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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-151-7/+7
| | | | | | | | | | | | | | | (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-141-7/+7
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-141-7/+7
| | | | | | | | | | | | | 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
* FunctionIndex is not optional for renameModuleForThinLTO(), make it a ↵Mehdi Amini2016-03-091-1/+1
| | | | | | | reference (NFC) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 262976
* Pass a std::unique_ptr to IRMover::move.Rafael Espindola2016-02-161-19/+19
| | | | | | | It was already the one "destroying" the source module, now the API reflects that. llvm-svn: 260989
* Delete the deprecated LLVMLinkModules.Rafael Espindola2016-02-121-34/+0
| | | | llvm-svn: 260683
* [ThinLTO] Move global processing from Linker to TransformUtils (NFC)Teresa Johnson2016-02-101-294/+6
| | | | | | | | | | | | | | | Summary: As discussed on IRC, move the ThinLTOGlobalProcessing code out of the linker, and into TransformUtils. The name of the class is changed to FunctionImportGlobalProcessing. Reviewers: joker.eph, rafael Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17081 llvm-svn: 260395
* [ThinLTO] Remove imported available externally defs from comdats.Teresa Johnson2016-02-081-2/+14
| | | | | | | | | | | | | | | 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
* [ThinLTO] Do metadata linking during batch function importingTeresa Johnson2016-01-221-2/+0
| | | | | | | | | | | | | | | | | | | | Summary: Since we are currently not doing incremental importing there is no need to link metadata as a postpass. The module linker will only link in the imported subroutines due to the functionality added by r256003. (Note that the metadata postpass linking functionalitiy is still used by llvm-link, and may be needed here in the future if a more incremental strategy is adopted.) Reviewers: joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16424 llvm-svn: 258458
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-6/+4
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* [ThinLTO] Use new in-place symbol changes for exporting moduleTeresa Johnson2016-01-081-7/+3
| | | | | | | | | | | | | | Due to the new in-place ThinLTO symbol handling support added in r257174, we now invoke renameModuleForThinLTO on the current module from within the FunctionImport pass. Additionally, renameModuleForThinLTO no longer needs to return the Module as it is performing the renaming in place on the one provided. This commit will be immediately preceeded by a companion clang patch to remove its invocation of renameModuleForThinLTO. llvm-svn: 257181
* [ThinLTO] Enable in-place symbol changes for exporting moduleTeresa Johnson2016-01-081-39/+114
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Move ThinLTO global value processing functions out of ModuleLinker and into a new ThinLTOGlobalProcessor class, which performs any necessary linkage and naming changes on the given module in place. As a result, renameModuleForThinLTO no longer needs to create a new Module when performing any necessary local to global promotion on a module that we are possibly exporting from during a ThinLTO backend compilation. During function importing the ThinLTO processing is still invoked from the ModuleLinker (via the new class), as it needs to perform renaming and linkage changes on the source module, e.g. in order to get the correct renaming during local to global promotion. Reviewers: joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D15696 llvm-svn: 257174
* [ThinLTO] Rename variable to reflect bulk importing change (NFC)Teresa Johnson2015-12-211-10/+11
| | | | llvm-svn: 256171
* Remove unused functions from ModuleLinker (NFC)Teresa Johnson2015-12-211-54/+0
| | | | | | | Remove a couple ModuleLinker methods and a related static function that are no longer used after the linker split. llvm-svn: 256162
* Rename variables to reflect linker split (NFC)Teresa Johnson2015-12-181-4/+4
| | | | | | | | Renamed variables to be more reflective of whether they are an instance of Linker, IRLinker or ModuleLinker. Also fix a stale comment. llvm-svn: 256011
* [ThinLTO] Metadata linking for imported functionsTeresa Johnson2015-12-171-5/+28
| | | | | | | | | | | | | | | | | | | | | | | Summary: Second patch split out from http://reviews.llvm.org/D14752. Maps metadata as a post-pass from each module when importing complete, suturing up final metadata to the temporary metadata left on the imported instructions. This entails saving the mapping from bitcode value id to temporary metadata in the importing pass, and from bitcode value id to final metadata during the metadata linking postpass. Depends on D14825. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14838 llvm-svn: 255909
* Mark a couple ModuleLinker member functions as const (NFC)Teresa Johnson2015-12-171-2/+2
| | | | llvm-svn: 255903
* Change linkInModule to take a std::unique_ptr.Rafael Espindola2015-12-161-7/+21
| | | | | | | Passing in a std::unique_ptr should help find errors when the module is used after being linked into another module. llvm-svn: 255842
* Use diagnostic handler in the LLVMContextRafael Espindola2015-12-141-17/+24
| | | | | | | | | | | | | | | | This patch converts code that has access to a LLVMContext to not take a diagnostic handler. This has a few advantages * It is easier to use a consistent diagnostic handler in a single program. * Less clutter since we are not passing a handler around. It does make it a bit awkward to implement some C APIs that return a diagnostic string. I will propose new versions of these APIs and deprecate the current ones. llvm-svn: 255571
* Avoid undefined behavior when vector is empty.Rafael Espindola2015-12-101-2/+1
| | | | | | Found by ubsan. llvm-svn: 255258
* Slit lib/Linker in two.Rafael Espindola2015-12-101-1273/+86
| | | | | | | | | | | | | | | | A linker normally has two stages: symbol resolution and "moving stuff". In lib/Linker there is the complication of lazy linking some globals, but it was still far more mixed than it needed to. This splits the linker into a lower level IRMover and the linker proper. The IRMover just takes a list of globals to move and a callback that lets the user control what is lazy linked. The main motivation is that now tools/gold (and soon lld) can use their own symbol resolution to instruct IRMover what to do. llvm-svn: 255254
* Synchronize the logic for deciding to link a gv.Rafael Espindola2015-12-091-1/+6
| | | | | | | We were deciding to not link an available_externally gv over a declaration, but then copying over the body anyway. llvm-svn: 255169
* Move all private members together. NFC.Rafael Espindola2015-12-081-23/+22
| | | | llvm-svn: 255021
* Factor two calls to a common location.Rafael Espindola2015-12-071-7/+3
| | | | llvm-svn: 254967
* Simplify the error handling a bit. NFC.Rafael Espindola2015-12-071-10/+9
| | | | llvm-svn: 254952
* Link declaration lazily.Rafael Espindola2015-12-071-0/+3
| | | | | | | We already linked available_externally and linkonce lazily, this just adds declarations to the list. llvm-svn: 254917
* Change how the linker handles the old llvm.global_ctors.Rafael Espindola2015-12-071-92/+34
| | | | | | | | | | | | | | | | | Now instead of changing it to the new format and then linking, it just handles the old format while copying it over. The main differences are: * There is no rauw in the source module. * An old format input is always upgraded. The first item helps with having a sane API that passes in a GV list to the linker. The second one is a small step in deprecating the old format. llvm-svn: 254907
OpenPOWER on IntegriCloud