[llvm-dev] [DWARF] using simplified template names

[via llvm-dev]

I’ve heard back from the Sony debugger folks, and dropping the <params> from the parent DIE’s name will have no bad effect on us.  We rebuild the <params> from the children, and we don’t currently make use of the index.  If this tactic goes under an option, we’d definitely like to have that set by default under sce-tuning to get the space savings.
--paulr


From: David Blaikie <dblaikie at gmail.com>
Sent: Monday, June 7, 2021 6:49 PM
To: Robinson, Paul <paul.robinson at sony.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Adrian Prantl <aprantl at apple.com>; Jonas Devlieghere <jdevlieghere at apple.com>; Henderson, James <James.Henderson at sony.com>; Caroline Tice <cmtice at google.com>; Eric Christopher <echristo at gmail.com>
Subject: Re: [DWARF] using simplified template names

On Mon, Jun 7, 2021 at 3:00 PM <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
Fully expanded names of template instantiations can become impressively large, yeah.

The DWARF Wiki’s Best Practices page http://wiki.dwarfstd.org/index.php?title=Best_Practices<https://urldefense.com/v3/__http:/wiki.dwarfstd.org/index.php?title=Best_Practices__;!!JmoZiZGBv3RvKRSx!o9KwsGo1xoYiOWlyAmsw893vZHwDXk2f3wKhdQsPeQFfIaGRCVQ_agzVb77WsSaubQ$> recommends including a canonical form of the template parameters in the DW_AT_name attribute.  I don’t know that I agree; it talks about omitting qualifiers (namespaces, containing classes) because those can be reconstructed from the DIE hierarchy, but the same argument can be made for template parameters (the difference being that qualifiers come from higher up the tree, while template parameters come from farther down).  The DRY principle would seem to apply here.

Ah, good to know - and yeah, the asymmetry between omitting namespace qualifiers but including parameters is noteworthy.

I’ll verify with our debugger team, but I’m confident that dropping the <params> from the type name will not affect Sony, as our debugger looks at the template-parameter children already (that’s why we have that turned on by default for sce tuning).  LLDB seems to be the odd debugger out, here, and we have some control over that. 😊

Ah, fascinating/good to know!

So even if /maybe/ we wouldn't want to do this for GDB tuning (I'd be a bit hesitant to diverge that much from GCC's defaults even if it seems to work (more testing to see how broadly it works) you might be interested in this being the default for SCE? That'd be good to do. I guess if we fix LLDB might be able to switch the defaults there too.

 Oh, is there any consequence for deduplication in LTO?  Isn’t that name-based?

Should be OK - that's based on the fully mangled/linkage name of the type, which would be untouched by this.

One quirk is that we probably can't do this for templates with pointer non-type template parameters (I haven't tested non-pointer non-type template parameters (such as integers, chars, etc) but I'd hope GDB can handle that and that would provide at least some "proof of concept") since they don't have an easy unambiguous stringification - even though you can only use a named variable/function/etc (ie: can't use an array offset, or other computed address) - neither GCC nor Clang encode that string, but instead encode the address (well, GCC doesn't even encode the address - so that debug info doesn't adversely affect code generation by causing the symbol to be linked in when it's otherwise unreferenced by the actual code) & so coming up with an unambiguous/consistent string to use in building the name would be a bit much. GDB doesn't seem to handle that situation. (says "UNKNOWN" or similar for the parameter, thus creating ambiguity when matching against others, etc)

The other area I'd be unsure about would be indexes - gdb index and DWARFv5 debug_names. We'll be indexing the linkage/mangled name (hmm, we don't do the linkage name for types - only for functions), and the simple name - but, as you point out - we were skipping namespaces already, so it's not like looking up "foo<int>" was unambiguous anyway - so they'll be a bit more ambiguous after this change. Some consumer performance impact - they'd have to search through more duplicates (take std::vector - now a consumer will have to go look at every CU that has any vector instantiation, whereas previously they were probably able to only look at the vector<int> instantiating CUs (& any nonstd::vector<int> out there as well) for instance).

- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210615/509dd05d/attachment-0001.html>