llvm/tools/gold/CMakeLists.txt

24 lines
522 B
CMake
Raw Normal View History

set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/gold.exports)
if( LLVM_ENABLE_PIC AND LLVM_BINUTILS_INCDIR )
include_directories( ${LLVM_BINUTILS_INCDIR} )
# Because off_t is used in the public API, the largefile parts are required for
# ABI compatibility.
add_definitions( -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 )
set(LLVM_LINK_COMPONENTS
${LLVM_TARGETS_TO_BUILD}
Linker
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270814 91177308-0d34-0410-b5e6-96231b3b80d8
2016-05-26 01:46:41 +00:00
LTO
BitWriter
IPO
)
add_llvm_loadable_module(LLVMgold
gold-plugin.cpp
)
endif()