[ThinLTO] Metadata linking for imported functions 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
Use diagnostic handler in the LLVMContext 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
Remove "ExportingModule" from ThinLTO Index (NFC) 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
Change ModuleLinker to take a set of GlobalValues to import instead of a 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
Use references now that it is natural to do so. 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
[ThinLTO] Deduplicate function index loading into shared helper (NFC) 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
llvm-link option and test for recent metadata mapping bug 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
Do not require a Context to extract the FunctionIndex from Bitcode (NFC) 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
Pass enum instead of bool to new linkInModule call in llvm-link 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
Restore "Support for ThinLTO function importing and symbol linking." 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
Revert "Support for ThinLTO function importing and symbol linking." 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
Support for ThinLTO function importing and symbol linking. 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
New bitcode linker flags: -only-needed -- link in only symbols needed by destination module -internalize -- internalize linked symbols Differential Revision: http://reviews.llvm.org/D12459 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246561 91177308-0d34-0410-b5e6-96231b3b80d8
Linker: Add flag to override linkage rules Add a flag to lib/Linker (and `llvm-link`) to override linkage rules. When set, the functions in the source module *always* replace those in the destination module. The `llvm-link` option is `-override=abc.ll`. All the "regular" modules are loaded and linked first, followed by the `-override` modules. This is useful for debugging workflows where some subset of the module (e.g., a single function) is extracted into a separate file where it's optimized differently, before being merged back in. Patch by Luqman Aden! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235473 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-link: Factor out loop over input files, NFC Factor the loop for linking input files together into a combined module into a separate function. This is in preparation for an upcoming patch that runs the logic twice. Patch by Luqman Aden! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235472 91177308-0d34-0410-b5e6-96231b3b80d8
uselistorder: Remove the global bits Remove all the global bits to do with preserving use-list order by moving the `cl::opt`s to the individual tools that want them. There's a minor functionality change to `libLTO`, in that you can't send in `-preserve-bc-uselistorder=false`, but making that bit settable (if it's worth doing) should be through explicit LTO API. As a drive-by fix, I removed some includes of `UseListOrder.h` that were made unnecessary by recent commits. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234973 91177308-0d34-0410-b5e6-96231b3b80d8
uselistorder: Pull the assembly bit up out of the printer Pull the `-preserve-ll-uselistorder` bit up through all the callers of `Module::print()`. I converted callers of `operator<<` to `Module::print()` where necessary to pull the bit through. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234968 91177308-0d34-0410-b5e6-96231b3b80d8