<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">probinson added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D14358#882445" rel="noreferrer" target="_blank">https://reviews.llvm.org/D14358#882445</a>, @dblaikie wrote:<br>
<br>
> > 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. :-)<br>
><br>
> Though you have this out of tree? How do you cope with LTO there?<br>
<br>
<br>
We discovered that we had to keep them in the name for LTO.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br>Fair enough - yeah, I would agree with Adrian that this probably isn't a driver flag (at least not yet), though. Either only driven by the debugger tuning (though perhaps we had some position that debugger tuning wouldn't ever be the only way to access functionality, only change defaults) or additionally a cc1 flag. Haven't thought about the name.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D14358" rel="noreferrer" target="_blank">https://reviews.llvm.org/D14358</a><br>
<br>
<br>
<br>
</blockquote></div></div>