paulkirth added inline comments.
================
Comment at: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:5080
+
+void llvm::embedBitcodeInFatObject(llvm::Module &M, llvm::MemoryBufferRef Buf)
{
+ // Save llvm.compiler.used and remove it.
----------------
Since this has been merged into this commit, I'll restate my concerns here from
D131090.
Does this just do what embed bitcode does? My understanding was that LTO
generated IR is emitted into object files differently than the embed bitcode
scenario. I'm basing that on the discussion at
https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977
What I mean is that the way `EmbedBitcode` worked was not `TheRightThing`
according to that discussion. It appears as though your change just copies its
logic.
So if I want to compile a C file and get a fat-LTO object, how does that work?
When do the LTO passes get added to the compilation pipeline? I don't mean the
big whole program optimization stuff that gets invoked at link-time, I mean the
module level passes and summary generation? It's not clear to me when those
will run after invoking clang on a source file, since I don't see any config
for setting that up as part of codegen.
can you elaborate on how this is intended to work? I seem to be missing
something. In particular, I'd like to some kind of documentation describing how
all the pieces are intended to work. I'd also like to see something outlining
any limitations, such as different combinations of object files/flags that are
not expected to work and //why//?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D131618/new/
https://reviews.llvm.org/D131618
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
