aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-link/llvm-link.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-12-02[llvm-link] use file magic when deciding if input should be loaded as archiveSergey Dmitriev1-14/+20
llvm-link should not rely on the '.a' file extension when deciding if input file should be loaded as archive. Archives may have other extensions (f.e. .lib) or no extensions at all. This patch changes llvm-link to use llvm::file_magic to check if input file is an archive. Reviewed By: RaviNarayanaswamy Differential Revision: https://reviews.llvm.org/D92376
2020-07-14llvm-link: Add support for archive files as inputsJan Sjodin1-1/+72
This patch adds support for archive files as inputs to llvm-link. One of the use-cases is for OpenMP, where device specific libraries need to be extracted from libraries containing bundled object files. The clang-offload-bundler will support extracting these archives, which will be passed into llvm-link, see https://reviews.llvm.org/D80816. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D81109
2020-07-08[opt] Remove obsolete --quiet optionArthur Eubanks1-1/+1
git blame shows these were last touched in 2004? Obsoleted in r13844. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D83409
2020-04-07[ThinLTO] Drop dso_local if a GlobalVariable satisfies isDeclarationForLinker()Fangrui Song1-2/+4
dso_local leads to direct access even if the definition is not within this compilation unit (it is still in the same linkage unit). On ELF, such a relocation (e.g. R_X86_64_PC32) referencing a STB_GLOBAL STV_DEFAULT object can cause a linker error in a -shared link. If the linkage is changed to available_externally, the dso_local flag should be dropped, so that no direct access will be generated. The current behavior is benign, because -fpic does not assume dso_local (clang/lib/CodeGen/CodeGenModule.cpp:shouldAssumeDSOLocal). If we do that for -fno-semantic-interposition (D73865), there will be an R_X86_64_PC32 linker error without this patch. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D74751
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-1/+1
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-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
2019-08-05Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song1-1/+1
F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-07-16Restore "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson1-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
2018-07-14Revert "[ThinLTO] Ensure we always select the same function copy to import"Teresa Johnson1-1/+1
This reverts commits r337050 and r337059. Caused failure in reverse-iteration bot that needs more investigation. llvm-svn: 337081
2018-07-13[ThinLTO] Ensure we always select the same function copy to importTeresa Johnson1-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
2018-04-18[llvm-link] Use WithColor for printing errorsJonas Devlieghere1-11/+18
Use convenience helpers in WithColor to print errors and warnings. Differential revision: https://reviews.llvm.org/D45667 llvm-svn: 330261
2018-04-13Define InitLLVM to do common initialization all at once.Rui Ueyama1-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
2018-02-21Revert "[IRMover] Implement name based structure type mapping"Rafael Espindola1-8/+1
This reverts commit r325686. There was a misunderstanding and this has not been approved yet. llvm-svn: 325715
2018-02-21[IRMover] Implement name based structure type mappingEugene Leviant1-1/+8
Differential revision: https://reviews.llvm.org/D43199 llvm-svn: 325686
2018-02-14Pass a reference to a module to the bitcode writer.Rafael Espindola1-1/+1
This simplifies most callers as they are already using references or std::unique_ptr. llvm-svn: 325155
2017-09-23[Support] Rename tool_output_file to ToolOutputFile, NFCReid Kleckner1-1/+1
This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions. llvm-svn: 314050
2017-09-15This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya1-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
2017-09-15This reverts r313381Vivek Pandya1-25/+20
llvm-svn: 313387
2017-09-15This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya1-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
2017-05-04Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne1-1/+1
the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
2017-05-04Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu1-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
2017-05-04IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne1-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
2017-05-01Object: Remove ModuleSummaryIndexObjectFile class.Peter Collingbourne1-1/+1
Differential Revision: https://reviews.llvm.org/D32195 llvm-svn: 301832
2017-03-13Remove unused lambda captureDavid Blaikie1-1/+1
llvm-svn: 297675
2017-03-13[Linker] Provide callback for internalizationJonas Devlieghere1-3/+20
Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
2017-01-04[ThinLTO] Rework llvm-link to use the FunctionImporterTeresa Johnson1-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
2016-11-14[ThinLTO] Only promote exported locals as marked in indexTeresa Johnson1-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
2016-11-11Bitcode: Change getModuleSummaryIndex() to return an llvm::Expected.Peter Collingbourne1-22/+6
Differential Revision: https://reviews.llvm.org/D26539 llvm-svn: 286624
2016-11-11Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson1-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
2016-11-09Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne1-3/+7
Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
2016-10-09[llvm-link] Fix description of -disable-lazy-loading optionDavide Italiano1-1/+1
Patch by Will Dietz! llvm-svn: 283697
2016-09-14Fix auto-upgrade of TBAA tags in Bitcode ReaderMehdi Amini1-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
2016-06-29Don't verify inputs to the Linker if ODR merging.Rafael Espindola1-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
2016-06-09Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith1-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
2016-05-27Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer1-1/+2
No functionality change intended, maybe a tiny performance improvement. llvm-svn: 270997
2016-04-21ThinLTO/ModuleLinker: add a flag to not always pull-in linkonce when ↵Mehdi Amini1-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
2016-04-19IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith1-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
2016-04-17IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith1-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
2016-04-14Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini1-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
2016-03-24[ThinLTO] Use bulk importing in llvm-linkTeresa Johnson1-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
2016-03-19Rework linkInModule(), making it oblivious to ThinLTOMehdi Amini1-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
2016-03-15[ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson1-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
2016-03-14Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson1-16/+17
This reverts commit r263490. Missed a file. llvm-svn: 263493
2016-03-14[ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson1-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
2016-02-16Pass a std::unique_ptr to IRMover::move.Rafael Espindola1-1/+1
It was already the one "destroying" the source module, now the API reflects that. llvm-svn: 260989
2016-01-21Revert obsolete llvm-link -preserve-modules option/testTeresa Johnson1-13/+0
This testing mode is now obsolete with the change to linkInModule to take a std::unique_ptr to Module. llvm-svn: 258399
2015-12-17[ThinLTO] Metadata linking for imported functionsTeresa Johnson1-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
2015-12-16Change linkInModule to take a std::unique_ptr.Rafael Espindola1-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
2015-12-14Use diagnostic handler in the LLVMContextRafael Espindola1-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
generated by cgit v1.1 at 2025-09-29 04:14:18 +0000