This is to prepare to allow for dead stripping of globals in the
merged modules.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/include/llvm/Bitcode/LLVMBitCodes.h | ||
---|---|---|
59 ↗ | (On Diff #101483) | Why use a different block ID? Since we are marking the module with a module flag, it doesn't seem necessary, and appears to be handled the same. I see your follow-on patch does something different based on the block id, but could/should that check the module flag instead? |
llvm/include/llvm/Bitcode/LLVMBitCodes.h | ||
---|---|---|
59 ↗ | (On Diff #101483) | answering my own question - I suppose we don't want to have to parse the module when interpreting the summary. |
llvm/include/llvm/Bitcode/LLVMBitCodes.h | ||
---|---|---|
59 ↗ | (On Diff #101483) | Because of how module flags are represented, they are hard to read directly out of bitcode. In general it would require parsing the entire metadata block, which is something that we should try to avoid doing on the linker's critical path. The simplest approach is to somehow store a "summary" of this particular module flag elsewhere in the bitcode, as I am doing here. |
59 ↗ | (On Diff #101483) | Right. |