maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/tools/gold/CMakeLists.txt

24 lines
522 B
CMake
Raw Normal View History

EXPORTED_SYMBOL_FILE support for cmake The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation in tools/clang/tools/libclang/CMakeLists.txt. This attempts to consolidate these one-offs into a single place. Clients can now just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in the make build. llvm-svn: 198136
2013-12-29 07:31:44 +08:00
set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/gold.exports)
Be less conservative about when we build the gold plugin. It is only build if LLVM_BINUTILS_INCDIR is explicitly given, so there is no point in having extra restrictions. llvm-svn: 223481
2014-12-06 01:25:52 +08:00
if( LLVM_ENABLE_PIC AND LLVM_BINUTILS_INCDIR )
Add LTO and gold plugin to the CMake build. Linux-only, support for other systems pending. PR9456. llvm-svn: 127466
2011-03-11 23:44:24 +08:00
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 )
Use lib/LTO directly in the gold plugin. The tools/lto API is not the best choice for implementing a gold plugin. Among other issues: * It is an stable ABI. Old errors stay and we have to be really careful before adding new features. * It has to support two fairly different linkers: gold and ld64. * We end up with a plugin that depends on a shared lib, something quiet unusual in LLVM land. * It hides LLVM. For some features in the gold plugin it would be really nice to be able to just get a Module or a GlobalValue. This change is intended to be a very direct translation from the C API. It will just enable other fixes and cleanups. Tested with a LTO bootstrap on linux. llvm-svn: 211315
2014-06-20 05:14:13 +08:00
set(LLVM_LINK_COMPONENTS
${LLVM_TARGETS_TO_BUILD}
Rewrite the gold plugin to fix pr19901. There is a fundamental difference between how the gold API and lib/LTO view the LTO process. The gold API talks about a particular symbol in a particular file. The lib/LTO API talks about a symbol in the merged module. The merged module is then defined in terms of the IR semantics. In particular, a linkonce_odr GV is only copied if it is used, since it is valid to drop unused linkonce_odr GVs. In the testcase in pr19901 both properties collide. What happens is that gold asks us to keep a particular linkonce_odr symbol, but the IR linker doesn't copy it to the merged module and we never have a chance to ask lib/LTO to keep it. This patch fixes it by having a more direct implementation of the gold API. If it asks us to keep a symbol, we change the linkage so it is not linkonce. If it says we can drop a symbol, we do so. All of this before we even send the module to lib/Linker. Since now we don't have to produce LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN, during symbol resolution we can use a temporary LLVMContext and do lazy module loading. This allows us to keep the minimum possible amount of allocated memory around. This should also allow as much parallelism as we want, since there is no shared context. llvm-svn: 216215
2014-08-22 04:28:55 +08:00
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 llvm-svn: 270814
2016-05-26 09:46:41 +08:00
LTO
Rewrite the gold plugin to fix pr19901. There is a fundamental difference between how the gold API and lib/LTO view the LTO process. The gold API talks about a particular symbol in a particular file. The lib/LTO API talks about a symbol in the merged module. The merged module is then defined in terms of the IR semantics. In particular, a linkonce_odr GV is only copied if it is used, since it is valid to drop unused linkonce_odr GVs. In the testcase in pr19901 both properties collide. What happens is that gold asks us to keep a particular linkonce_odr symbol, but the IR linker doesn't copy it to the merged module and we never have a chance to ask lib/LTO to keep it. This patch fixes it by having a more direct implementation of the gold API. If it asks us to keep a symbol, we change the linkage so it is not linkonce. If it says we can drop a symbol, we do so. All of this before we even send the module to lib/Linker. Since now we don't have to produce LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN, during symbol resolution we can use a temporary LLVMContext and do lazy module loading. This allows us to keep the minimum possible amount of allocated memory around. This should also allow as much parallelism as we want, since there is no shared context. llvm-svn: 216215
2014-08-22 04:28:55 +08:00
BitWriter
IPO
Use lib/LTO directly in the gold plugin. The tools/lto API is not the best choice for implementing a gold plugin. Among other issues: * It is an stable ABI. Old errors stay and we have to be really careful before adding new features. * It has to support two fairly different linkers: gold and ld64. * We end up with a plugin that depends on a shared lib, something quiet unusual in LLVM land. * It hides LLVM. For some features in the gold plugin it would be really nice to be able to just get a Module or a GlobalValue. This change is intended to be a very direct translation from the C API. It will just enable other fixes and cleanups. Tested with a LTO bootstrap on linux. llvm-svn: 211315
2014-06-20 05:14:13 +08:00
)
Add LTO and gold plugin to the CMake build. Linux-only, support for other systems pending. PR9456. llvm-svn: 127466
2011-03-11 23:44:24 +08:00
add_llvm_loadable_module(LLVMgold
gold-plugin.cpp
)
Restore the library dependency of LLVMgold on LTO; this was removed recently but is needed for LLVMgold to load in ld. llvm-svn: 198965
2014-01-11 06:48:35 +08:00
Fixing build break: should be in the if statement, not outside. llvm-svn: 198966
2014-01-11 06:55:25 +08:00
endif()