aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Linker/LinkModules.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-01-16GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob1-6/+4
Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
2016-01-08[ThinLTO] Use new in-place symbol changes for exporting moduleTeresa Johnson1-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
2016-01-08[ThinLTO] Enable in-place symbol changes for exporting moduleTeresa Johnson1-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
2015-12-21[ThinLTO] Rename variable to reflect bulk importing change (NFC)Teresa Johnson1-10/+11
llvm-svn: 256171
2015-12-21Remove unused functions from ModuleLinker (NFC)Teresa Johnson1-54/+0
Remove a couple ModuleLinker methods and a related static function that are no longer used after the linker split. llvm-svn: 256162
2015-12-18Rename variables to reflect linker split (NFC)Teresa Johnson1-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
2015-12-17[ThinLTO] Metadata linking for imported functionsTeresa Johnson1-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
2015-12-17Mark a couple ModuleLinker member functions as const (NFC)Teresa Johnson1-2/+2
llvm-svn: 255903
2015-12-16Change linkInModule to take a std::unique_ptr.Rafael Espindola1-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
2015-12-14Use diagnostic handler in the LLVMContextRafael Espindola1-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
2015-12-10Avoid undefined behavior when vector is empty.Rafael Espindola1-2/+1
Found by ubsan. llvm-svn: 255258
2015-12-10Slit lib/Linker in two.Rafael Espindola1-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
2015-12-09Synchronize the logic for deciding to link a gv.Rafael Espindola1-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
2015-12-08Move all private members together. NFC.Rafael Espindola1-23/+22
llvm-svn: 255021
2015-12-07Factor two calls to a common location.Rafael Espindola1-7/+3
llvm-svn: 254967
2015-12-07Simplify the error handling a bit. NFC.Rafael Espindola1-10/+9
llvm-svn: 254952
2015-12-07Link declaration lazily.Rafael Espindola1-0/+3
We already linked available_externally and linkonce lazily, this just adds declarations to the list. llvm-svn: 254917
2015-12-07Change how the linker handles the old llvm.global_ctors.Rafael Espindola1-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
2015-12-04[ThinLTO] Helper for performing renaming/promotion on a moduleTeresa Johnson1-0/+12
Creates a module and performs necessary renaming/promotion of locals that may be exported to another module. Split out of D15024. llvm-svn: 254802
2015-12-04Always pass a diagnostic handler to the linker.Rafael Espindola1-10/+0
Before this patch the diagnostic handler was optional. If it was not passed, the one in the LLVMContext was used. That is probably not a pattern we want to follow. If each area has an optional callback, there is a sea of callbacks and it is hard to follow which one is called. Doing this also found cases where the callback is a nice addition, like testing that no errors or warnings are reported. The other option is to always use the diagnostic handler in the LLVMContext. That has a few problems * To implement the C API we would have to set the diag handler and then set it back to the original value. * Code that creates the context might be far away from code that wants the diagnostics. I do have a patch that implements the second option and will send that as an RFC. llvm-svn: 254777
2015-12-03[ThinLTO] Appending linkage fixesTeresa Johnson1-5/+9
Summary: Fix import from module with appending var, which cannot be imported. The first fix is to remove an overly-aggressive error check. The second fix is to deal with restructuring introduced to the module linker yesterday in r254418 (actually, this fix was included already in r254559, just added some additional cleanup). Test by Mehdi Amini. Reviewers: joker.eph, rafael Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15156 llvm-svn: 254624
2015-12-03Simplify ValueMap handling.Rafael Espindola1-42/+49
We now just return values and let ValueMap handle the map. llvm-svn: 254615
2015-12-03Don't pass member variables to member functions. NFC.Rafael Espindola1-17/+12
llvm-svn: 254610
2015-12-03Adapt comment and rename variable in ModuleLinker to describe more ↵Mehdi Amini1-4/+4
accurately the actual use. Thanks Sean Silva for the suggestion. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 254582
2015-12-03Remove "ExportingModule" from ThinLTO Index (NFC)Mehdi Amini1-1/+1
There is no real reason the index has to have the concept of an exporting Module. We should be able to have one single unique instance of the Index, and it should be read-only after creation for the whole ThinLTO processing. The linker plugin should be able to process multiple modules (in parallel or in sequence) with the same index. The only reason the ExportingModule was present seems to be to implement hasExportedFunctions() that is used by the Module linker to decide what to do with the current Module. For now I replaced it with a query to the map of Modules path to see if this module was declared in the Index and consider that if it is the case then it is probably exporting function. On the long term the Linker interface needs to evolve and this call should not be needed anymore. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 254581
2015-12-02Switch the linker to having a whitelist of GVs.Rafael Espindola1-51/+67
This replaces DoNotLinkFromSource with ValuesToLink. It also moves the computation of ValuesToLink earlier. It is a bit simpler and an important step in slitting the linker into an ir mover and a linker proper. The test change is because we now avoid creating dead declarations. llvm-svn: 254559
2015-12-02Delete what is now duplicated code.Rafael Espindola1-28/+3
Having to import an alias as declaration is not thinlto specific. The test difference are because when we already have a decl and we are not importing it, we just leave the decl alone. llvm-svn: 254556
2015-12-02Also copy private linkage globals when needed.Rafael Espindola1-1/+1
This was an omission when handling COFF style comdats with local keys. Should fix the sanitizer-windows bot. llvm-svn: 254543
2015-12-02Don't copy information from aliasee to alias.Rafael Espindola1-6/+1
They are independent. llvm-svn: 254541
2015-12-02Fix linking when we copy over only a decl.Rafael Espindola1-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
2015-12-02Change ModuleLinker to take a set of GlobalValues to import instead of a ↵Mehdi Amini1-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
2015-12-01Use default member initializers.Rafael Espindola1-4/+3
llvm-svn: 254473
2015-12-01Remove unnecessary getter.Rafael Espindola1-4/+1
llvm-svn: 254466
2015-12-01Pass down the dst GV to linkGlobalValueBody. NFC.Rafael Espindola1-9/+7
llvm-svn: 254465
2015-12-01Delete unused includes.Rafael Espindola1-9/+0
llvm-svn: 254457
2015-12-01clang-format LinkModules.cpp.Rafael Espindola1-19/+19
Most of the file has been changed recently and was already clang-format clean. llvm-svn: 254454
2015-12-01Use references now that it is natural to do so.Rafael Espindola1-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
2015-12-01Delete dead code.Rafael Espindola1-5/+0
llvm-svn: 254436
2015-12-01Use a forwarding constructor instead of an init method.Rafael Espindola1-10/+5
llvm-svn: 254435
2015-12-01Delete the setModule method from the Linker.Rafael Espindola1-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
2015-12-01Make appending var linking less of a special case.Rafael Espindola1-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
2015-12-01Bring r254336 back:Rafael Espindola1-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
2015-11-30This reverts commit r254336 and r254344.Rafael Espindola1-76/+77
They broke a bot and I am debugging why. llvm-svn: 254347
2015-11-30Disable a consistency check.Rafael Espindola1-5/+1
Trying to figure out why it fails on a bot but passes locally. llvm-svn: 254344
2015-11-30Start deciding earlier what to link.Rafael Espindola1-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
2015-11-30Fix another llvm.ctors merging bug.Rafael Espindola1-2/+3
We were not looking past casts to see if an element should be included or not. llvm-svn: 254313
2015-11-29Simplify. NFC.Rafael Espindola1-16/+12
llvm-svn: 254254
2015-11-29Correctly handle llvm.global_ctors merging.Rafael Espindola1-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
2015-11-29Fix a crash when writing merged bitcode.Rafael Espindola1-5/+14
Playing with mutateType in here was making getValueType and getType incompatible. llvm-svn: 254240
2015-11-27Simplify the linking of recursive data.Rafael Espindola1-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
generated by cgit v1.1 at 2025-10-10 05:29:22 +0000