mirror of
https://github.com/RPCSX/llvm.git
synced 2025-01-01 17:28:26 +00:00
08d0e94685
Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@298638 91177308-0d34-0410-b5e6-96231b3b80d8
42 lines
1.4 KiB
LLVM
42 lines
1.4 KiB
LLVM
; Test to make sure the thinlto-object-suffix-replace option is handled
|
|
; correctly.
|
|
|
|
; Generate bitcode file with summary, as well as a minimized bitcode without
|
|
; the debug metadata for the thin link.
|
|
; RUN: opt -thinlto-bc %s -thin-link-bitcode-file=%t1.thinlink.bc -o %t1.o
|
|
|
|
; First perform the thin link on the normal bitcode file, and save the
|
|
; resulting index.
|
|
; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
|
|
; RUN: -m elf_x86_64 \
|
|
; RUN: --plugin-opt=thinlto \
|
|
; RUN: --plugin-opt=thinlto-index-only \
|
|
; RUN: -shared %t1.o -o %t3
|
|
; RUN: cp %t1.o.thinlto.bc %t1.o.thinlto.bc.orig
|
|
|
|
; Next perform the thin link on the minimized bitcode file, and compare dump
|
|
; of the resulting index to the above dump to ensure they are identical.
|
|
; RUN: rm -f %t1.o.thinlto.bc
|
|
; Make sure it isn't inadvertently using the regular bitcode file.
|
|
; RUN: rm -f %t1.o
|
|
; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
|
|
; RUN: -m elf_x86_64 \
|
|
; RUN: --plugin-opt=thinlto \
|
|
; RUN: --plugin-opt=thinlto-index-only \
|
|
; RUN: --plugin-opt=thinlto-object-suffix-replace=".thinlink.bc;.o" \
|
|
; RUN: -shared %t1.thinlink.bc -o %t3
|
|
; RUN: diff %t1.o.thinlto.bc.orig %t1.o.thinlto.bc
|
|
|
|
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
|
|
define void @f() {
|
|
entry:
|
|
ret void
|
|
}
|
|
|
|
!llvm.dbg.cu = !{}
|
|
|
|
!1 = !{i32 2, !"Debug Info Version", i32 3}
|
|
!llvm.module.flags = !{!1}
|