aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorMircea Trofin <mtrofin@google.com>2020-09-10 12:16:26 -0700
committerMircea Trofin <mtrofin@google.com>2020-09-11 13:24:54 -0700
commit9a2bab5ea2f4aacbb267e634ff1189fa64143b76 (patch)
tree17101d37e9da1b0fea168a5112524ed8117567fe /clang/lib/Frontend/CompilerInvocation.cpp
parent59fc86779038b19cf85f87b51052d468286788f2 (diff)
downloadllvm-9a2bab5ea2f4aacbb267e634ff1189fa64143b76.zip
llvm-9a2bab5ea2f4aacbb267e634ff1189fa64143b76.tar.gz
llvm-9a2bab5ea2f4aacbb267e634ff1189fa64143b76.tar.bz2
[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
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions