aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ObjectFile.cpp
diff options
context:
space:
mode:
authorPaul Kirth <paulkirth@google.com>2023-03-24 00:21:51 +0000
committerPaul Kirth <paulkirth@google.com>2023-06-23 23:23:58 +0000
commit44265dc3554ef40920b587eeb787a400663af6c7 (patch)
treec640fb33c118738f40fec5d523dd479dd6152cc5 /llvm/lib/Object/ObjectFile.cpp
parent83835e22c7cd50c0e9b836cc359b6c59985b921f (diff)
downloadllvm-44265dc3554ef40920b587eeb787a400663af6c7.zip
llvm-44265dc3554ef40920b587eeb787a400663af6c7.tar.gz
llvm-44265dc3554ef40920b587eeb787a400663af6c7.tar.bz2
Reland [llvm] Preliminary fat-lto-objects support
Fat LTO objects contain both LTO compatible IR, as well as generated object code. This allows users to defer the choice of whether to use LTO or not to link-time. This is a feature available in GCC for some time, and makes the existing -ffat-lto-objects flag functional in the same way as GCC's. Within LLVM, we add a new EmbedBitcodePass that serializes the module to the object file, and expose a new pass pipeline for compiling fat objects. The new pipeline initially clones the module and runs the selected (Thin)LTOPrelink pipeline, after which it will serialize the module into a `.llvm.lto` section of an ELF file. When compiling for (Thin)LTO, this normally the point at which the compiler would emit a object file containing the bitcode and metadata. After that point we compile the original module using the PerModuleDefaultPipeline used for non-LTO compilation. We generate standard object files at the end of this pipeline, which contain machine code and the new `.llvm.lto` section containing bitcode. Since the two pipelines operate on different copies of the module, we can be sure that the bitcode in the `.llvm.lto` section and object code in `.text` are congruent with the existing output produced by the default and LTO pipelines. Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977 Earlier versions of this patch were missing REQUIRES lines for llc related tests in Transforms/EmbedBitcode. Those tests are now under CodeGen/X86, which should avoid running the check on unsupported platforms. Reviewed By: tejohnson, MaskRay, nikic Differential Revision: https://reviews.llvm.org/D146776
Diffstat (limited to 'llvm/lib/Object/ObjectFile.cpp')
-rw-r--r--llvm/lib/Object/ObjectFile.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/llvm/lib/Object/ObjectFile.cpp b/llvm/lib/Object/ObjectFile.cpp
index c953a56..0820187 100644
--- a/llvm/lib/Object/ObjectFile.cpp
+++ b/llvm/lib/Object/ObjectFile.cpp
@@ -79,7 +79,7 @@ uint32_t ObjectFile::getSymbolAlignment(DataRefImpl DRI) const { return 0; }
bool ObjectFile::isSectionBitcode(DataRefImpl Sec) const {
Expected<StringRef> NameOrErr = getSectionName(Sec);
if (NameOrErr)
- return *NameOrErr == ".llvmbc";
+ return *NameOrErr == ".llvmbc" || *NameOrErr == ".llvm.lto";
consumeError(NameOrErr.takeError());
return false;
}