[all-commits] [llvm/llvm-project] 75a179: Reland [llvm] Preliminary fat-lto-objects support

[Paul Kirth via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 75a1797044fc049438bdfd1edaf16afa90fcfe24
      https://github.com/llvm/llvm-project/commit/75a1797044fc049438bdfd1edaf16afa90fcfe24
  Author: Paul Kirth <paulkirth at google.com>
  Date:   2023-06-28 (Wed, 28 Jun 2023)

  Changed paths:
    A llvm/docs/FatLTO.rst
    M llvm/docs/ReleaseNotes.rst
    M llvm/docs/UserGuides.rst
    M llvm/include/llvm/Passes/PassBuilder.h
    A llvm/include/llvm/Transforms/IPO/EmbedBitcodePass.h
    M llvm/lib/IR/StructuralHash.cpp
    M llvm/lib/Object/ObjectFile.cpp
    M llvm/lib/Passes/PassBuilder.cpp
    M llvm/lib/Passes/PassBuilderPipelines.cpp
    M llvm/lib/Passes/PassRegistry.def
    M llvm/lib/Transforms/IPO/CMakeLists.txt
    A llvm/lib/Transforms/IPO/EmbedBitcodePass.cpp
    A llvm/test/CodeGen/X86/fat-lto-section.ll
    A llvm/test/Transforms/EmbedBitcode/embed-multiple.ll
    A llvm/test/Transforms/EmbedBitcode/embed-unsupported-object-format.ll
    A llvm/test/Transforms/EmbedBitcode/embed.ll

  Log Message:
  -----------
  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.

The EmbedbBitcodePass also returned PreservedAnalyses::all when adding a
metadata section, which failed expensive checks, since it modified the
module. This is now corrected.

Reviewed By: tejohnson, MaskRay, nikic

Differential Revision: https://reviews.llvm.org/D146776