aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
diff options
context:
space:
mode:
authorPeter Collingbourne <peter@pcc.me.uk>2014-09-18 21:28:49 +0000
committerPeter Collingbourne <peter@pcc.me.uk>2014-09-18 21:28:49 +0000
commit10039c02ea1d34d39fb3b66f522c53bb50751da5 (patch)
treed0fcaa82f000b5ef6f140be711ae02155192c4fd /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
parent6bf091c656f319e36721364fe50c456efca36df6 (diff)
downloadllvm-10039c02ea1d34d39fb3b66f522c53bb50751da5.zip
llvm-10039c02ea1d34d39fb3b66f522c53bb50751da5.tar.gz
llvm-10039c02ea1d34d39fb3b66f522c53bb50751da5.tar.bz2
LTO: introduce object file-based on-disk module format.
This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions