summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker
Commit message (Collapse)AuthorAgeFilesLines
...
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-71/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ValueMapper: Extract llvm::RemapFunction from IRMover.cpp, NFCDuncan P. N. Exon Smith2016-04-081-25/+8
| | | | | | | | | | | | | | Strip out the remapping parts of IRLinker::linkFunctionBody and put them in ValueMapper.cpp under the name Mapper::remapFunction (with a top-level entry-point llvm::RemapFunction). This is a nice cleanup on its own since it puts the remapping code together and shares a single Mapper context for the entire IRLinker::linkFunctionBody Call. Besides that, this will make it easier to break the co-recursion between IRMover.cpp and ValueMapper.cpp in follow ups. llvm-svn: 265835
* Linker: Always pass RF_IgnoreMissingLocals; NFCDuncan P. N. Exon Smith2016-04-081-3/+3
| | | | | | | | | | | This is a cleanup after clarifying the meaning of RF_IgnoreMissingLocals in r265628 and truly limiting it to locals in r265768. This should have no functionality change, since the only context that the flag has an effect is when we could hit function-local Value and Metadata, and we were already passing it in those contexts. llvm-svn: 265831
* IR: RF_IgnoreMissingValues => RF_IgnoreMissingLocals, NFCDuncan P. N. Exon Smith2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Clarify what this RemapFlag actually means. - Change the flag name to match its intended behaviour. - Clearly document that it's not supposed to affect globals. - Add a host of FIXMEs to indicate how to fix the behaviour to match the intent of the flag. RF_IgnoreMissingLocals should only affect the behaviour of RemapInstruction for function-local operands; namely, for operands of type Argument, Instruction, and BasicBlock. Currently, it is *only* passed into RemapInstruction calls (and the transitive MapValue calls that it makes). When I split Metadata from Value I didn't understand the flag, and I used it in a bunch of places for "global" metadata. This commit doesn't have any functionality change, but prepares to cleanup MapMetadata and MapValue. llvm-svn: 265628
* IRMover: Steal arguments when moving functions, NFCDuncan P. N. Exon Smith2016-04-061-19/+6
| | | | | | | | | | | | | | | | | | Instead of copying arguments from the source function to the destination, steal them. This has a few advantages. - The ValueMap doesn't need to be seeded with (or cleared of) Arguments. - Often the destination function won't have created any arguments yet, so this avoids malloc traffic. - Argument names don't need to be copied. Because argument lists are lazy, this required a new Function::stealArgumentListFrom helper. llvm-svn: 265519
* Linker: Split mapUnneededSubprograms into two; almost NFCDuncan P. N. Exon Smith2016-04-021-11/+15
| | | | | | | | | | | | | | Split the loop through compile units in mapUnneededSubprograms in two. First, visit imported entities to ensure that we've visited all need subprograms. Second, visit subprograms, and drop the ones we don't need. Hypothetically this protects against a subprogram from one compile unit being referenced from an imported entity in a different compile unit. I don't think that's valid IR (a debug info expert could confirm), but I think the refactor makes the code more clear. llvm-svn: 265233
* Remove redundant assertion after cast, NFCDuncan P. N. Exon Smith2016-04-021-1/+0
| | | | llvm-svn: 265232
* Linker: Avoid unnecessary work when moving named metadataDuncan P. N. Exon Smith2016-04-021-17/+11
| | | | | | | | | | | IRLinker::mapUnneededSubprograms has to be sure that any "needed" subprograms get linked in. Rather than traversing through imported entities using llvm::getSubprogram, call MapMetadata. The latter memoizes the result in the ValueMap (sharing work with IRLinker::linkNamedMDNodes proper), and makes the local SmallPtrSet redundant. llvm-svn: 265231
* Linker: Remove IRMover::isMetadataUnneeded indirection; almost NFCDuncan P. N. Exon Smith2016-04-021-48/+19
| | | | | | | | | | | | | | | | Instead of checking live during MapMetadata whether a subprogram is needed, seed the ValueMap with `nullptr` up-front. There is a small hypothetical functionality change. Previously, calling MapMetadataOp on a node whose "scope:" chain led to an unneeded subprogram would return nullptr. However, if that were ever called, then the subprogram would be needed; a situation that the IRMover is supposed to avoid a priori! Besides cleaning up the code a little, this restores a nice property: MapMetadataOp returns the same as MapMetadata. llvm-svn: 265229
* ValueMapper: Add support for seeding metadata with nullptrDuncan P. N. Exon Smith2016-04-021-1/+1
| | | | | | | | | | | | | Support seeding a ValueMap with nullptr for Metadata entries, a situation I didn't consider in the Metadata/Value split. I added a ValueMapper::getMappedMD accessor that returns an Optional<Metadata*> with the mapped (possibly null) metadata. IRMover needs to use this to avoid modifying the map when it's checking for unneeded subprograms. I updated a call from bugpoint since I find the new code clearer. llvm-svn: 265228
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-292-246/+15
| | | | | | | | | | | 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
* Minor cleanup and documentation to IRMover (NFC)Mehdi Amini2016-03-111-20/+32
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263304
* Materialize metadata in IRLinker before value mappingTeresa Johnson2016-03-101-5/+6
| | | | | | | | | | | | | | | | | | | Summary: Unless we plan to do later postpass metadata linking (ThinLTO special mode), always invoke metadata materialization at the start of IRLinker::run(). This avoids the need for clients who use lazy metadata loading to explicitly invoke materializeMetadata before the IRMover, which in turn invokes IRLinker::run and needs materialized metadata for mapping. Came up in the context of an LLD issue (D17982). Reviewers: rafael Subscribers: silvas, llvm-commits Differential Revision: http://reviews.llvm.org/D17992 llvm-svn: 263143
* 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-162-55/+57
| | | | | | | 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
* Improve efficiency of handling unmapped subprogram metadataTeresa Johnson2016-01-281-25/+28
| | | | | | | | | | | | | | | | The stripNullSubprograms function is very inefficient because it walks all subprograms in all compile units in the dest module any time a new module is linked in. For LTO in particular this will get increasingly expensive as more modules are linked. This patch improves the efficiency in several ways. The first is that no scanning is necessary when there were no unneeded subprograms identified in the first place. The second is that only the newly-linked module's compile unit metadata should be examined. Fixes PR26346. llvm-svn: 259049
* Remove autoconf supportChris Bieneman2016-01-261-15/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
* [ThinLTO] Find all needed metadata when linking metadata as postpassTeresa Johnson2016-01-251-6/+27
| | | | | | | | | For metadata postpass linking, after importing all functions, we need to recursively walk through any nodes reached via imported functions to locate needed subprogram metadata. Some might only be reached indirectly via the variable list for an inlined function. llvm-svn: 258728
* [ThinLTO] Handle DISubprogram reached indirectly from DIImportedEntityTeresa Johnson2016-01-251-2/+4
| | | | | | | Extend fix for PR26037 to identify DISubprogram reached from a DIImportedEntity via a DILexicalBlock. llvm-svn: 258722
* [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
* Use early return to simplify code (NFC)Teresa Johnson2016-01-211-22/+21
| | | | | | Follow on to r258405. llvm-svn: 258407
* [ThinLTO] Avoid unnecesary hash lookups during metadata linking (NFC)Teresa Johnson2016-01-211-16/+16
| | | | | | | Replace sequences of count() followed by operator[] with either find() or insert(), depending on the context. llvm-svn: 258405
* Remove redundant argument.Rafael Espindola2016-01-211-3/+3
| | | | | | It is already a member variable. llvm-svn: 258369
* Simplify the logic. NFC.Rafael Espindola2016-01-201-19/+2
| | | | | | Found while reviewing the change for PR26152. llvm-svn: 258362
* Fix PR26152.Evgeniy Stepanov2016-01-201-1/+1
| | | | | | | | Fix the condition for when the new global takes over the name of the existing one to be the negation of the condition for the new global to get internal linkage. llvm-svn: 258355
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-162-12/+10
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* [IRMover] Don't copy personality, etc unless creating defTeresa Johnson2016-01-121-0/+10
| | | | | | | | | | | | | | Function::copyAttributesFrom will copy the personality function, prefix data and prolog data from the source function to the new function, and is invoked when the IRMover copies the function prototype. This puts a reference to a constant in the source module on a function in the dest module, which causes an error when deleting the source module after importing, since the personality function in the source module still has uses (this would presumably also be an issue for the prologue and prefix data). Remove the copies added to the dest copy when creating the new prototype, as they are mapped properly when/if we link the function body. llvm-svn: 257420
* [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
* [Linker] Also treat a DIImportedEntity scope DISubprogram as needed.Ahmed Bougacha2016-01-071-1/+3
| | | | | | | | | Follow-up to r257000: DIImportedEntity can reach a DISubprogram via its entity, but also via its scope. Handle the latter case as well. PR26037. llvm-svn: 257019
* Always treat DISubprogram reached by DIImportedEntity as needed.Teresa Johnson2016-01-071-1/+11
| | | | | | | | | | It is illegal to have a null entity in a DIImportedEntity, so we must link in a DISubprogram metadata node referenced by one, even if the associated function is not linked in or inlined anywhere. Fixes PR26037. llvm-svn: 257000
* [ThinLTO] Rename variables used in metadata linking (NFC)Teresa Johnson2015-12-301-2/+4
| | | | | | | | As suggested in review for r255909, rename MDMaterialized to AllowTemps, and identify the name of the boolean flag being set in calls to saveMetadataList. llvm-svn: 256653
* Ensure MDNode used as key in metadata linking map cannot be RAUWedTeresa Johnson2015-12-301-0/+17
| | | | | | | | | | | | As suggested in review for r255909, add a way to ensure that temporary MD used as keys in the MetadataToID map during ThinLTO importing are not RAUWed. Add support for marking an MDNode as not replaceable. Clear the new CanReplace flag when adding a temporary MD node to the MetadataToID map and clear it when destroying the map. llvm-svn: 256648
* Rename MDValue* to Metadata* (NFC)Teresa Johnson2015-12-291-10/+10
| | | | | | | Renamed MDValue* to Metadata*, and MDValueToValIDMap to MetadataToIDs, as per review for r255909. llvm-svn: 256593
* Handle empty Subprogram list when linking metadata.Teresa Johnson2015-12-221-1/+1
| | | | | | | | Use an iterator that handles an empty subprogram list. Fixes PR25915. llvm-svn: 256224
* [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
* Drop support for dematerializing.Rafael Espindola2015-12-181-1/+0
| | | | | | | It was only used on lib/Linker and the use was "dead" since it was used on a function the IRMover had just moved. llvm-svn: 256019
OpenPOWER on IntegriCloud