[all-commits] [llvm/llvm-project] 9a2bab: [ThinLTO] Make -lto-embed-bitcode an enum

[Mircea Trofin via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 9a2bab5ea2f4aacbb267e634ff1189fa64143b76
      https://github.com/llvm/llvm-project/commit/9a2bab5ea2f4aacbb267e634ff1189fa64143b76
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2020-09-11 (Fri, 11 Sep 2020)

  Changed paths:
    M llvm/lib/LTO/LTOBackend.cpp
    M llvm/test/LTO/X86/embed-bitcode.ll

  Log Message:
  -----------
  [ThinLTO] Make -lto-embed-bitcode an enum

The current behavior of -lto-embed-bitcode is not quite the same as that
of -fembed-bitcode. While both populate .llvmbc with bitcode, the latter
populates it with pre-optimized bitcode(*), while the former with
post-optimized. The scenarios driving them are different - the latter's
goal is to allow re-compilation, while the former, IIUC, is execution.

I plan to add a third mode for thinlto cases, closely-related to
-fembed-bitcode's scenario: adding the bitcode pre-optimization, but
post-merging. This would allow re-compilation without requiring the
other .bc files that were merged (akin to how -fembed-bitcode allows
recompilation without all the .h files)

The third mode can't co-exist with the current -lto-embed-bitcode mode,
because the latter would overwrite it. For clarity, we change
-lto-embed-bitcode to be an enum.

(*) That's the compiler semantics. The driver splits compilation in 2
phases, so if -fembed-bitcode is given to the driver, the .llvmbc is
optimized bitcode; if the option is passed to the compiler (after -cc1),
the section is pre-optimized.

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