[all-commits] [llvm/llvm-project] ab9b3c: [lld] A Unified LTO Bitcode Frontend

[Matthew Voss via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ab9b3c84a588f86e7f66eeb577bea7155817ff06
      https://github.com/llvm/llvm-project/commit/ab9b3c84a588f86e7f66eeb577bea7155817ff06
  Author: Matthew Voss <matthew.voss at sony.com>
  Date:   2023-07-18 (Tue, 18 Jul 2023)

  Changed paths:
    M lld/ELF/Config.h
    M lld/ELF/Driver.cpp
    M lld/ELF/LTO.cpp
    M lld/ELF/Options.td
    A lld/test/ELF/lto/unified-lto.ll

  Log Message:
  -----------
  [lld] A Unified LTO Bitcode Frontend

The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.

Example usage:

clang -flto -funified-lto -fuse-ld=lld foo.c

clang -flto=thin -funified-lto -fuse-ld=lld foo.c

clang -c -flto -funified-lto foo.c  # -flto={full,thin} are identical in
terms of compilation actions
clang -flto=thin -fuse-ld=lld foo.o # pass --lto=thin to ld.lld

clang -c -flto -funified-lto foo.c clang -flto -fuse-ld=lld foo.o

The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774

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