probinson added a comment. In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
> > I would prefer to eliminate the `<params>` from the instance name as well, > > because our debugger reconstructs a name more to its liking from the > > parameter children. However, IIUC the name with params is used for > > deduplication in LTO, so that is probably not such a good idea. :-) > > Though you have this out of tree? How do you cope with LTO there? We discovered that we had to keep them in the name for LTO. > I've not fully refreshed myself on the previous conversations - but it looks > like my thought was that this state proposed here is weird/inconsistent: The > parameters are already in the name, so adding them in the DIEs seems > redundant. If the parameters weren't in the name then this change might make > more sense. Our debugger throws away the params in the name, and relies on the children. The names as rendered in DWARF by Clang are not textually consistent with names as rendered by the demangler. Our debugger uses the children to construct names that are consistent with how the demangler works. Then it can match up type names returned by the demangler to type names it has constructed. Assuming I am not misunderstanding our debugger guys again, but that's my recollection. I believe we have talked previously about using a different scheme for deduplication that doesn't depend (or not so much) on the names. If we had that, we could eliminate params from the name, and save probably a noticeable chunk of space in the string section. I haven't tried to measure that, though. But we have to have the children in place before we can experiment with other deduplication schemes. There is also the pedantic point that DWARF doesn't say these child entries are optional, or omitted for forward declarations. I know gcc doesn't (or didn't, anyway; what I have locally is gcc 5.4) but gcc is not the arbiter of what constitutes conforming DWARF. https://reviews.llvm.org/D14358 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
