[PATCH] D154923: [CodeGen] Support bitcode input containing multiple modules
Fangrui Song via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 14 13:45:52 PDT 2023
MaskRay added a comment.
In D154923#4491673 <https://reviews.llvm.org/D154923#4491673>, @MaskRay wrote:
> In D154923#4491411 <https://reviews.llvm.org/D154923#4491411>, @efriedma wrote:
>
>> If I follow correctly, this is basically undoing the splitting that was done by the command that produced the bitcode file?
>
> Yes, undoing `llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp` change that would make the output bitcode file not usable as an input for non-LTO use cases.
>
>> I guess that could be useful. But it requires either renaming your object files from the default ".o" to ".bc", or explicitly passing "-x ir"? That seems unintuitive. Maybe it's better to put this behind some explicit flag?
>
> Yes, specify `-x ir` or let the driver deduce the file type with the predefined extension `.bc`.
>
> I think this is a less common operation (compiling with LTO but then using as non-LTO), so I think adding another option seems not necessary.
Perhaps rephrase my argument:
There are multiple ways to have just one module in a bitcode file output: `-Xclang -fno-lto-unit`, not using features like -fsanitize=cfi, using -fsanitize=cfi with `-fno-split-lto-unit`.
I think whether a bitcode input file contains 2 modules (internal implementation strategy) should not be a criterion to require an additional driver option when the user seek for a non-LTO compile action.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154923/new/
https://reviews.llvm.org/D154923
More information about the cfe-commits
mailing list