[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