[Bug debug/49312] Make DW_AT_name contain only simple name, no template-id

["dblaikie at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49312

David Blaikie <dblaikie at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dblaikie at gmail dot com

--- Comment #4 from David Blaikie <dblaikie at gmail dot com> ---
FWIW I've (partially) implemented this in Clang under the flag
`-gsimple-template-names` due to some really large debug info issues with
(especially eigen and tensorflow) expression templates (I saw template names as
long as 50k characters leading to exceeding the 32 bit limit in .debug_str.dwo
sections in dwp files (and gold dwp didn't check for overflow, so this caused
silent corruption)).

There certainly are some issues with it - my approach didn't simplify all names
- certain names aren't easy to roundtrip from the DIE descriptions of the
template parameters (lambdas are a great/difficult example, for instance - the
lambda type DIEs don't have anything about the lambda mangling number, etc, and
maybe should - so even in non-template cases the lambdas could be matched up
between two TUs (lambdas in inline functions are the same type even in
different translation units & should be treated as such))

So there's a bunch of work that'd probably need to be done on template DIE
accuracy/completeness before this feature could be adopted wholesale without
any exemptions, but for the size benefits (especially in expression template
heavy code) I've found it to be worthwhile & we've done some work to flesh out
support for this in lldb as well as identify maybe a couple of gdb bugs related
to this.

I've tried to poke dwarf-discuss about the lambda issue in particular (
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-August/007117.html
) but no one seems interested in discussing it. So maybe it's something
GCC/Clang/GDB/LLDB folks should discuss more directly together.

Also some recent discussion with Simon Marchi on the gdb list:
https://sourceware.org/pipermail/gdb/2023-January/050496.html