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

Cool - good to know!

(out of curiosity, any idea what the Sony debugger does for pointer
template parameters? At least GCC doesn't seem to be able to reconstruct
those back into strings (you'd basically have to symbolize the address
value of the parameter (GCC doesn't even encode this value, so it's not
surprising GDB doesn't try to do anything when it's present)) - so
I'll
probably implement this under a flag but not include (ie: use the current
full textual encoding) any template with a pointer template parameter)

eg: extern int i; template<int *> void f1() { } int main() {
f1<&i>(); }

On Mon, Jun 14, 2021 at 7:00 PM <paul.robinson at sony.com> wrote:
> 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> 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/20210614/d5b0e9f9/attachment.html>

> (out of curiosity, any idea what the Sony debugger does for
> pointer template parameters? At least GCC doesn't seem to be
> able to reconstruct those back into strings (you'd basically
> have to symbolize the address value of the parameter (GCC
> doesn't even encode this value, so it's not surprising GDB
> doesn't try to do anything when it's present)) - so I'll
> probably implement this under a flag but not include (ie: use
> the current full textual encoding) any template with a pointer
> template parameter)
>
> eg: extern int i; template<int *> void f1() { } int main() {
f1<&i>(); }
Nice catch, we don't do anything clever here either.  This would
appear to be a special case of non-type template params that can
be arbitrary compile-time expressions; for non-pointer params we 
provide the computed value of the compile-time expression, which 
is arguably sufficient for cases like

  constexpr int a = 1; constexpr int b = 2;
  template <int> void f2() { }
  void int_expr() { f2<a + b>(); }

but it would be nice to do something useful for

  extern int j[4];
  void ptr_expr() { f1<&j[a+b]>(); }

We can't repurpose DW_AT_name for this because that's the 
template parameter's formal name; nothing else comes to mind,
maybe we need a new attribute for this.
--paulr