summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-link/llvm-link.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-2/+2
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* 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
* Restore "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson2018-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r337081, therefore restoring r337050 (and fix in r337059), with test fix for bot failure described after the original description below. In order to always import the same copy of a linkonce function, even when encountering it with different thresholds (a higher one then a lower one), keep track of the summary we decided to import. This ensures that the backend only gets a single definition to import for each GUID, so that it doesn't need to choose one. Move the largest threshold the GUID was considered for import into the current module out of the ImportMap (which is part of a larger map maintained across the whole index), and into a new map just maintained for the current module we are computing imports for. This saves some memory since we no longer have the thresholds maintained across the whole index (and throughout the in-process backends when doing a normal non-distributed ThinLTO build), at the cost of some additional information being maintained for each invocation of ComputeImportForModule (the selected summary pointer for each import). There is an additional map lookup for each callee being considered for importing, however, this was able to subsume a map lookup in the Worklist iteration that invokes computeImportForFunction. We also are able to avoid calling selectCallee if we already failed to import at the same or higher threshold. I compared the run time and peak memory for the SPEC2006 471.omnetpp benchmark (running in-process ThinLTO backends), as well as for a large internal benchmark with a distributed ThinLTO build (so just looking at the thin link time/memory). Across a number of runs with and without this change there was no significant change in the time and memory. (I tried a few other variations of the change but they also didn't improve time or peak memory). The new commit removes a test that no longer makes sense (Transforms/FunctionImport/hotness_based_import2.ll), as exposed by the reverse-iteration bot. The test depends on the order of processing the summary call edges, and actually depended on the old problematic behavior of selecting more than one summary for a given GUID when encountered with different thresholds. There was no guarantee even before that we would eventually pick the linkonce copy with the hottest call edges, it just happened to work with the test and the old code, and there was no guarantee that we would end up importing the selected version of the copy that had the hottest call edges (since the backend would effectively import only one of the selected copies). Reviewers: davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D48670 llvm-svn: 337184
* Revert "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson2018-07-141-1/+1
| | | | | | | This reverts commits r337050 and r337059. Caused failure in reverse-iteration bot that needs more investigation. llvm-svn: 337081
* [ThinLTO] Ensure we always select the same function copy to importTeresa Johnson2018-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to always import the same copy of a linkonce function, even when encountering it with different thresholds (a higher one then a lower one), keep track of the summary we decided to import. This ensures that the backend only gets a single definition to import for each GUID, so that it doesn't need to choose one. Move the largest threshold the GUID was considered for import into the current module out of the ImportMap (which is part of a larger map maintained across the whole index), and into a new map just maintained for the current module we are computing imports for. This saves some memory since we no longer have the thresholds maintained across the whole index (and throughout the in-process backends when doing a normal non-distributed ThinLTO build), at the cost of some additional information being maintained for each invocation of ComputeImportForModule (the selected summary pointer for each import). There is an additional map lookup for each callee being considered for importing, however, this was able to subsume a map lookup in the Worklist iteration that invokes computeImportForFunction. We also are able to avoid calling selectCallee if we already failed to import at the same or higher threshold. I compared the run time and peak memory for the SPEC2006 471.omnetpp benchmark (running in-process ThinLTO backends), as well as for a large internal benchmark with a distributed ThinLTO build (so just looking at the thin link time/memory). Across a number of runs with and without this change there was no significant change in the time and memory. (I tried a few other variations of the change but they also didn't improve time or peak memory). Reviewers: davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D48670 llvm-svn: 337050
* [llvm-link] Use WithColor for printing errorsJonas Devlieghere2018-04-181-11/+18
| | | | | | | | Use convenience helpers in WithColor to print errors and warnings. Differential revision: https://reviews.llvm.org/D45667 llvm-svn: 330261
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-8/+2
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* Revert "[IRMover] Implement name based structure type mapping"Rafael Espindola2018-02-211-8/+1
| | | | | | | | This reverts commit r325686. There was a misunderstanding and this has not been approved yet. llvm-svn: 325715
* [IRMover] Implement name based structure type mappingEugene Leviant2018-02-211-1/+8
| | | | | | Differential revision: https://reviews.llvm.org/D43199 llvm-svn: 325686
* Pass a reference to a module to the bitcode writer.Rafael Espindola2018-02-141-1/+1
| | | | | | | This simplifies most callers as they are already using references or std::unique_ptr. llvm-svn: 325155
* [Support] Rename tool_output_file to ToolOutputFile, NFCReid Kleckner2017-09-231-1/+1
| | | | | | | This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions. llvm-svn: 314050
* This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya2017-09-151-20/+25
| | | | | | | | | | | It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with command line options. The diagnostic handler used to be callback now this patch adds a class DiagnosticHandler. It has virtual method to provide custom diagnostic handler and methods to control which particular remarks are enabled. However LLVM-C API users can still provide callback function for diagnostic handler. llvm-svn: 313390
* This reverts r313381Vivek Pandya2017-09-151-25/+20
| | | | llvm-svn: 313387
* This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya2017-09-151-20/+25
| | | | | | | | | | | It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with command line options. The diagnostic handler used to be callback now this patch adds a class DiagnosticHandler. It has virtual method to provide custom diagnostic handler and methods to control which particular remarks are enabled. However LLVM-C API users can still provide callback function for diagnostic handler. llvm-svn: 313382
* Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne2017-05-041-1/+1
| | | | | | | | the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
* Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu2017-05-041-1/+1
| | | | | | | | | | summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. llvm-svn: 302140
* IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne2017-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | NFCI. When profiling a no-op incremental link of Chromium I found that the functions computeImportForFunction and computeDeadSymbols were consuming roughly 10% of the profile. The goal of this change is to improve the performance of those functions by changing the map lookups that they were previously doing into pointer dereferences. This is achieved by changing the ValueInfo data structure to be a pointer to an element of the global value map owned by ModuleSummaryIndex, and changing reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs. This means that a ValueInfo will take a client directly to the summary list for a given GUID. Differential Revision: https://reviews.llvm.org/D32471 llvm-svn: 302108
* Object: Remove ModuleSummaryIndexObjectFile class.Peter Collingbourne2017-05-011-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D32195 llvm-svn: 301832
* Remove unused lambda captureDavid Blaikie2017-03-131-1/+1
| | | | llvm-svn: 297675
* [Linker] Provide callback for internalizationJonas Devlieghere2017-03-131-3/+20
| | | | | | Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
* [ThinLTO] Rework llvm-link to use the FunctionImporterTeresa Johnson2017-01-041-35/+16
| | | | | | | | | | | | | | | | | | | | Summary: Change llvm-link to use the FunctionImporter handling, instead of manually invoking the Linker. We still need to load the module in llvm-link to do the desired testing for invalid import requests (weak functions), and to get the GUID (in case the function is local). Also change the drop-debug-info test to use llvm-link so that importing is forced (in order to test debug info handling) and independent of import logic changes. Reviewers: mehdi_amini Subscribers: mgorny, llvm-commits, aprantl Differential Revision: https://reviews.llvm.org/D28277 llvm-svn: 290964
* [ThinLTO] Only promote exported locals as marked in indexTeresa Johnson2016-11-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We have always speculatively promoted all renamable local values (except const non-address taken variables) for both the exporting and importing module. We would then internalize them back based on the ThinLink results if they weren't actually exported. This is inefficient, and results in unnecessary renames. It also meant we had to check the non-renamability of a value in the summary, which was already checked during function importing analysis in the ThinLink. Made renameModuleForThinLTO (which does the promotion/renaming) instead use the index when exporting, to avoid unnecessary renames/promotions. For importing modules, we can simply promoted all values as any local we import by definition is exported and needs promotion. This required changes to the method used by the FunctionImport pass (only invoked from 'opt' for testing) and when invoked from llvm-link, since neither does a ThinLink. We simply conservatively mark all locals in the index as promoted, which preserves the current aggressive promotion behavior. I also needed to change an llvm-lto based test where we had previously been aggressively promoting values that weren't importable (aliasees), but now will not promote. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26467 llvm-svn: 286871
* Bitcode: Change getModuleSummaryIndex() to return an llvm::Expected.Peter Collingbourne2016-11-111-22/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D26539 llvm-svn: 286624
* Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson2016-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Split ReaderWriter.h which contains the APIs into both the BitReader and BitWriter libraries into BitcodeReader.h and BitcodeWriter.h. This is to address Chandler's concern about sharing the same API header between multiple libraries (BitReader and BitWriter). That concern is why we create a single bitcode library in our downstream build of clang, which led to r286297 being reverted as it added a dependency that created a cycle only when there is a single bitcode library (not two as in upstream). Reviewers: mehdi_amini Subscribers: dlj, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D26502 llvm-svn: 286566
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-3/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* [llvm-link] Fix description of -disable-lazy-loading optionDavide Italiano2016-10-091-1/+1
| | | | | | Patch by Will Dietz! llvm-svn: 283697
* Fix auto-upgrade of TBAA tags in Bitcode ReaderMehdi Amini2016-09-141-4/+11
| | | | | | | | | | | | | | | | | | If TBAA is on an intrinsic and it gets upgraded, it'll delete the call instruction that we collected in a vector. Even if we were to use WeakVH, it'll drop the TBAA and we'll hit the assert on the upgrade path. r263673 gave a shot to make sure the TBAA upgrade happens before intrinsics upgrade, but failed to account for all cases. Instead of collecting instructions in a vector, this patch makes it just upgrade the TBAA on the fly, because metadata are always already loaded at this point. Differential Revision: https://reviews.llvm.org/D24533 llvm-svn: 281549
* Don't verify inputs to the Linker if ODR merging.Rafael Espindola2016-06-291-1/+4
| | | | | | | | | | | | | | | | | | 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
* Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith2016-06-091-1/+1
| | | | | | | looking for it along $PATH. This allows installs of LLVM tools outside of $PATH to find the symbolizer and produce pretty backtraces if they crash. llvm-svn: 272232
* Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer2016-05-271-1/+2
| | | | | | No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
* ThinLTO/ModuleLinker: add a flag to not always pull-in linkonce when ↵Mehdi Amini2016-04-211-2/+4
| | | | | | | | | | | | | | | | | | | 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
* IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith2016-04-191-1/+1
| | | | | | | | | | | As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes llvm-svn: 266713
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-141-1/+1
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* [ThinLTO] Use bulk importing in llvm-linkTeresa Johnson2016-03-241-56/+89
| | | | | | | | | | | | | | | Summary: Use bulk importing so we can avoid the use of post-pass metadata linking. Cloned the ModuleLazyLoaderCache from the FunctionImport pass to facilitate this. Reviewers: joker.eph Subscribers: dexonsmith, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18455 llvm-svn: 264326
* Rework linkInModule(), making it oblivious to ThinLTOMehdi Amini2016-03-191-10/+19
| | | | | | | | | | | | | | | | | | | | | | | | 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-17/+16
| | | | | | | | | | | | | | | (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-16/+17
| | | | | | This reverts commit r263490. Missed a file. llvm-svn: 263493
* [ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson2016-03-141-17/+16
| | | | | | | | | | | | | 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
* Pass a std::unique_ptr to IRMover::move.Rafael Espindola2016-02-161-1/+1
| | | | | | | It was already the one "destroying" the source module, now the API reflects that. llvm-svn: 260989
* Revert obsolete llvm-link -preserve-modules option/testTeresa Johnson2016-01-211-13/+0
| | | | | | | This testing mode is now obsolete with the change to linkInModule to take a std::unique_ptr to Module. llvm-svn: 258399
* [ThinLTO] Metadata linking for imported functionsTeresa Johnson2015-12-171-7/+42
| | | | | | | | | | | | | | | | | | | | | | | 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
* Change linkInModule to take a std::unique_ptr.Rafael Espindola2015-12-161-2/+2
| | | | | | | 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-1/+7
| | | | | | | | | | | | | | | | 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
* Rename Set variable to be pluralMehdi Amini2015-12-031-3/+3
| | | | | | | Thanks Sean Silva for catching this. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 254584
* Remove "ExportingModule" from ThinLTO Index (NFC)Mehdi Amini2015-12-031-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
* Change ModuleLinker to take a set of GlobalValues to import instead of a ↵Mehdi Amini2015-12-021-1/+4
| | | | | | | | | | | | 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 references now that it is natural to do so.Rafael Espindola2015-12-011-3/+3
| | | | | | | 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
* [ThinLTO] Deduplicate function index loading into shared helper (NFC)Teresa Johnson2015-11-231-23/+4
| | | | | | | | Add a shared helper routine to read the function index from a file and create/return the function index object. Use it in llvm-link and llvm-lto. llvm-svn: 253903
OpenPOWER on IntegriCloud