Page MenuHomePhabricator

[ThinLTO] Make -lto-embed-bitcode an enum
ClosedPublic

Authored by mtrofin on Sep 10 2020, 12:23 PM.

Details

Summary

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.

Diff Detail

Event Timeline

mtrofin created this revision.Sep 10 2020, 12:23 PM
mtrofin requested review of this revision.Sep 10 2020, 12:23 PM
mtrofin edited the summary of this revision. (Show Details)Sep 10 2020, 12:32 PM
mtrofin edited the summary of this revision. (Show Details)Sep 11 2020, 10:39 AM

The change itself looks good to me, but I don't understand this comment from the summary:

(*) 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.

Are you saying that "clang -fembed-bitcode foo.c -O2 -c" does something different than "clang -cc1 -fembed-bitcode foo.c -O2 -c". That seems strange and broken to me. I thought the intent of the option is to emit pre-optimized code.

The change itself looks good to me, but I don't understand this comment from the summary:

(*) 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.

Are you saying that "clang -fembed-bitcode foo.c -O2 -c" does something different than "clang -cc1 -fembed-bitcode foo.c -O2 -c". That seems strange and broken to me. I thought the intent of the option is to emit pre-optimized code.

That's indeed how it works. I was also under the same impression (by looking at the code). The semantic nuance can be derived from the RFC (specifically, http://lists.llvm.org/pipermail/llvm-dev/2016-February/094907.html), albeit, TBH, it took me a bit to put the 2 together (i.e. what the RFC said with what I saw in code).

This revision is now accepted and ready to land.Sep 11 2020, 11:03 AM
This revision was automatically updated to reflect the committed changes.

@mtrofin this change (and related changes in other reviews) look good to me! I'm currently on parental leave so I am no able to review in a timely manner. However, I'd appreciate if you could keep me in the loop for -lto-embed-bitcode related changes. Thanks in advance!