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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
