Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 30 Nov 2006, Mark Mitchell wrote:

> As an FYI, mangle_class_name_for_template has nothing to do with 
> name-mangling, in the usual sense.  It's a misnamed routine.  (I've 
> vaguely meant to rename for about ten years.)  It's actual job is to 
> create human-readable names for class template specializations.

Right, those generated names are the used by debug info (they can be seen 
in the AT_name tags).  That of course only makes sense for stuff for which 
we actually generate debug info, which isn't the case for incomplete types 
for which we nevertheless generate those (superlong) identifiers.

> Semantically, you should be able to completely remove this routine, and 
> not see any testsuite failures.

That was our guess too, until Richard tried :)  We tried different things
(see also Richards initial postings about this PR):

1 just making it NULL --> ICEs all over
2 letting it be all get_identifier("42") --> some testsuite errors 
  (not many, though) where it's clear that somehow some identifiers were 
  merged where they shouldn't be
3 letting it be get_identifier(itoa(TYPE_UID(type)) --> works, it's just
  that the debug info will contain incorrect names (a type named "1253" is 
  not that informative :-) )
4 letting it be get_identifier(itoa(static_number++)) --> works but has 
  the same problem as TYPE_UID
5 letting it be the _mangled_ name of the type --> works mostly, except 
  that incomplete types can't be mangled all the time (ICEs in the 
  mangler).  All those types have the property that they won't be emitted 
  in debug info, hence there we could use the TYPE_UID approach above.  
  With this there were strange problems with PCH, and it looked quite 
  hacky as you had to look at the type to determine if that one can not be 
  fed into the mangler, and that predicate got complicated.  This has the 
  advantage that the debugger can still get at the real name as it just 
  has to demangle it.
6 the approach you see here now, which IMHO is a bit worse than 5 because 
  it merges some names by leaving out scopes of identifiers

>From all that it _seems_ that something besides the debugging functions do 
look at those DECL_NAMES and actually require some property.  My 
speculation was that it was required that different types (and the problem 
here are the not yet complete types build during parsing or so) need to 
have different DECL_NAMEs for this purpose, as approach 3 and 4 worked.  
But only mostly, there were strange PCH problems.

Given that, though, it is a mystery to me why approach 6 actually seems to 
work, as that one uses the same name for different entities sometimes.

We weren't really able to pinpoint where exactly the DECL_NAME seems to 
matter for (incomplete) types and had hoped that someone else would know 
:-(  Without that knowledge all the patches while saving quite some memory 
seem to be just black magic working by pure luck.


Ciao,
Michael.