<div dir="ltr">I think I'm down to one of the last pieces for rebuilding the names & being able to round-trip them through llvm-dwarfdump --verify: <a href="https://reviews.llvm.org/D111477">https://reviews.llvm.org/D111477</a> - in case anyone's got opinions on what we should do with integer type suffixes on non-type template parameters.<br><br>A few other remaining pieces:<br>1) make the "operator" detection a bit better: <a href="https://github.com/llvm/llvm-project/blob/main/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp#L308-L311">https://github.com/llvm/llvm-project/blob/main/llvm/lib/DebugInfo/DWARF/DWARFDie.cpp#L308-L311</a> - Don't think we can rely on there being a space after the word "operator" (because it might be "operator<" for instance) so maybe I just need a full regex/exhaustive list of valid identifier characters, so if it's "operator" followed by an identifier character, then it doesn't trigger this special case? Or the inverse - special case all the whitespace+first characters in operator overloads. That's probably a smaller set.<br>2) Integrate this into llvm-symbolizer so it rebuilds the names automatically<br><br>Then there's some lldb bugs to fix, etc.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 23, 2021 at 3:06 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 23, 2021 at 1:14 PM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br>
><br>
> >> Oh, is there any consequence for deduplication in LTO?  Isn’t that name-based?<br>
><br>
> > Should be OK - that's based on the fully mangled/linkage name of the type, which would be untouched by this.<br>
><br>
> I’ve recently been reminded that type-unit signatures are hashes of the name, not using the standard-recommended algorithm of hashing the content; I tried to work out which name is actually used, but it’s buried deeper than I am comfortable excavating.  Can we make sure that hash is using either the name-with-parameters, or the linkage name, as the input string?  We don’t want “foo<int>” and “foo<float>” using the same type-unit signature!<br>
<br>
Worth checking, but yeah, not a problem - we don't emit class linkage<br>
names, so the only reason we carry the linkage name on types is for<br>
ODR deduplicating during LTO linking, and also using it for type units<br>
when those are enabled - the linkage name is stored in the<br>
DICompositeType's "identifier" field - not something readily confused<br>
with being guaranteed to be the linkage name nor used for<br>
DW_AT_linkage_name, etc. Only used as a unique identifier. That won't<br>
be touched.<br>
<br>
<br>
As an aside: I do have another direction I'm interested in pursuing<br>
that's related to linkage names, rather than the pretty names: We<br>
could reduce the number of DW_AT_linkage_names we emit by<br>
reconstituting linkage names in symbolizers instead (eg: if we see a<br>
function called "f3" with a single "int" formal parameter and void<br>
return type - we can reconstruct the linkage name for that function as<br>
_Zf3iv or whatever it is).<br>
<br>
On one particularly pathological case I'm looking at, the simplified<br>
pretty template names is worth 43% reduction in the final dwp<br>
.debug_str.dwo and a rough estimate on the linkage name (omitting<br>
linkage names from most cases when Clang's building the IR - there are<br>
certain kinds of template cases that are hard to reconstruct, but<br>
others that are easy/do-able with our current DWARF) 52%, and combined<br>
for 95% reduction in debug string size. (a less pathalogical case, one<br>
of Google's largest binaries, it was 26%/56% for 82% total reduction)<br>
</blockquote></div>