summaryrefslogtreecommitdiff
path: root/tools/llvm-link
AgeCommit message (Collapse)Author
2017-09-23[Support] Rename tool_output_file to ToolOutputFile, NFCReid Kleckner
This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314050 91177308-0d34-0410-b5e6-96231b3b80d8
2017-09-15This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313390 91177308-0d34-0410-b5e6-96231b3b80d8
2017-09-15This reverts r313381Vivek Pandya
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313387 91177308-0d34-0410-b5e6-96231b3b80d8
2017-09-15This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313382 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-04Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne
the module summary. NFCI." with a fix for the clang backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302176 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-04Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu
summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302140 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-04IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302108 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-01llvm-link: Add BitReader to deps corresponding to r301832.NAKAMURA Takumi
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301850 91177308-0d34-0410-b5e6-96231b3b80d8
2017-05-01Object: Remove ModuleSummaryIndexObjectFile class.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D32195 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301832 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-13Remove unused lambda captureDavid Blaikie
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297675 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-13[Linker] Provide callback for internalizationJonas Devlieghere
Differential Revision: https://reviews.llvm.org/D30738 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297649 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-04[ThinLTO] Rework llvm-link to use the FunctionImporterTeresa Johnson
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290964 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-19[CMake] llvm-link depends on intrinsics_genChris Bieneman
llvm-link.cpp has the following include chain: llvm/Bitcode/BitcodeWriter.h llvm/IR/ModuleSummaryIndex.h llvm/IR/Module.h llvm/IR/Function.h llvm/IR/Argument.h llvm/IR/Attributes.h llvm/IR/Attributes.gen This means llvm-link needs to depend on intrinsics_gen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287431 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-14[ThinLTO] Only promote exported locals as marked in indexTeresa Johnson
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286871 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-11Bitcode: Change getModuleSummaryIndex() to return an llvm::Expected.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26539 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286624 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-11Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286566 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-09Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26439 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286382 91177308-0d34-0410-b5e6-96231b3b80d8
2016-10-09[llvm-link] Fix description of -disable-lazy-loading optionDavide Italiano
Patch by Will Dietz! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283697 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-14Fix auto-upgrade of TBAA tags in Bitcode ReaderMehdi Amini
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281549 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-29Don't verify inputs to the Linker if ODR merging.Rafael Espindola
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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274148 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-09Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272232 91177308-0d34-0410-b5e6-96231b3b80d8
2016-05-27Apply clang-tidy's misc-move-constructor-init throughout LLVM.Benjamin Kramer
No functionality change intended, maybe a tiny performance improvement. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270997 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-21ThinLTO/ModuleLinker: add a flag to not always pull-in linkonce when ↵Mehdi Amini
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266948 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-19IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith
As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266713 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-17IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith
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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266549 91177308-0d34-0410-b5e6-96231b3b80d8
2016-04-14Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266379 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-24[ThinLTO] Use bulk importing in llvm-linkTeresa Johnson
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264326 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-19Add a dependency from llvm-link to TransformUtils following r263860Mehdi Amini
From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263873 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-19Rework linkInModule(), making it oblivious to ThinLTOMehdi Amini
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263863 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-15[ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson
(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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263513 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-14Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"Teresa Johnson
This reverts commit r263490. Missed a file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263493 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-14[ThinLTO] Renaming of function index to module summary index (NFC)Teresa Johnson
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263490 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-16Pass a std::unique_ptr to IRMover::move.Rafael Espindola
It was already the one "destroying" the source module, now the API reflects that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260989 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-26Remove autoconf supportChris Bieneman
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258861 91177308-0d34-0410-b5e6-96231b3b80d8
2016-01-21Revert obsolete llvm-link -preserve-modules option/testTeresa Johnson
This testing mode is now obsolete with the change to linkInModule to take a std::unique_ptr to Module. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258399 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-17[ThinLTO] Metadata linking for imported functionsTeresa Johnson
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255909 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-16Change linkInModule to take a std::unique_ptr.Rafael Espindola
Passing in a std::unique_ptr should help find errors when the module is used after being linked into another module. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255842 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-14Use diagnostic handler in the LLVMContextRafael Espindola
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255571 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-03Rename Set variable to be pluralMehdi Amini
Thanks Sean Silva for catching this. From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254584 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-03Remove "ExportingModule" from ThinLTO Index (NFC)Mehdi Amini
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254581 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-02Change ModuleLinker to take a set of GlobalValues to import instead of a ↵Mehdi Amini
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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254486 91177308-0d34-0410-b5e6-96231b3b80d8
2015-12-01Use references now that it is natural to do so.Rafael Espindola
The linker never takes ownership of a module or changes which module it is refering to, making it natural to use references. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254449 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-23[ThinLTO] Deduplicate function index loading into shared helper (NFC)Teresa Johnson
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253903 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-23Remove unused function parameter (NFC)Teresa Johnson
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253889 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-21llvm-link option and test for recent metadata mapping bugTeresa Johnson
Summary: Add a -preserve-modules option to llvm-link that simulates LTO clients that don't destroy modules as they are linked. This enables reproduction of a recent bug introduced by a metadata linking change that was only caught when the modules weren't destroyed before writing bitcode (LTO on Windows). See http://llvm.org/viewvc/llvm-project?view=revision&revision=253170 for more details on the original bug and the fix. Confirmed the new test added here reproduces the failure using the new option when I suppress the fix. Reviewers: pcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14818 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253740 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-19Do not require a Context to extract the FunctionIndex from Bitcode (NFC)Mehdi Amini
The LLVMContext was only used for Diagnostic. Pass a DiagnosticHandler instead. Differential Revision: http://reviews.llvm.org/D14794 From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253540 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-03Pass enum instead of bool to new linkInModule call in llvm-linkTeresa Johnson
A new call I added to linkInModule from llvm-link in r251866 was still passing in a boolean for an argument that was changed to an enum in r246561. I didn't catch this in my merge since the bool false matched the flag value it mapped to. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251925 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-03Restore "Support for ThinLTO function importing and symbol linking."Teresa Johnson
This restores commit r251837, with the new library dependence added to llvm-link/Makefile to address bot failures. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251866 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-02Revert "Support for ThinLTO function importing and symbol linking."Teresa Johnson
This reverts commit r251837, due to a number of bot failures of the form: /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::create(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::Module const*, bool)' /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.obj/tools/llvm-link/Release+Asserts/llvm-link.o:llvm-link.cpp:function loadIndex(llvm::LLVMContext&, llvm::Module const*): error: undefined reference to 'llvm::object::FunctionIndexObjectFile::takeIndex()' I'm not sure why these are happening - I added Object to the requred libraries in tools/llvm-link/LLVMBuild.txt and the LLVM_LINK_COMPONENTS in tools/llvm-link/CMakeLists.txt. Confirmed for my build that these symbols come out of libLLVMObject.a. What am I missing? git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251841 91177308-0d34-0410-b5e6-96231b3b80d8
2015-11-02Support for ThinLTO function importing and symbol linking.Teresa Johnson
Summary: Support for necessary linkage changes and symbol renaming during ThinLTO function importing. Also includes llvm-link support for manually importing functions and associated llvm-link based tests. Note that this does not include support for intelligently importing metadata, which is currently imported duplicate times. That support will be in the follow-on patch, and currently is ignored by the tests. Reviewers: dexonsmith, joker.eph, davidxl Subscribers: tobiasvk, tejohnson, llvm-commits Differential Revision: http://reviews.llvm.org/D13515 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251837 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-06 17:14:27 +0000