This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory
- From: Michael Matz <matz at suse dot de>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, mrs at apple dot com
- Date: Fri, 1 Dec 2006 19:49:43 +0100 (CET)
- Subject: Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory
- References: <Pine.LNX.firstname.lastname@example.org> <456FD641.email@example.com>
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.