luxufan wrote: > @luxufan I think we may need changes on the LLVM side before we can make > progress here -- either to clarify what `unnamed_addr` is intended to mean, > or perhaps to split it into separate attributes for cloning and merging. > > But before we go down that path, this PR doesn't describe the motivation for > this change, so it'd be useful to get an idea of how much of a difference you > expect this to make. Are you seeing a lot of duplicated symbols containing > type manglings?
@zygoloid In our downstream project, we are trying to remove redundant RTTI data (type info and type name strings) in ThinLTO. To avoid some undefined symbols errors after elimination, I need to check the CanAutoHide flag https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/ModuleSummaryIndex.h#L500 to decide if the symbol can be eliminated. The CanAutoHide flag is implied by function https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/ModuleSummaryIndex.h#L500 which is partly implied by the unnamed_addr attribute. So if type info or type name string can be marked as unnamed_addr or local_unnamed_addr, it makes our implementation simple and correct. Of course, mark as unnamed_addr or local_unnamed_addr is one of the solution, I can also add an extra flags in the module summary index to solve our problem. https://github.com/llvm/llvm-project/pull/111343 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
