This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, 12 Dec 2006, Daniel Jacobowitz wrote:

> On Tue, Dec 12, 2006 at 04:16:07PM +0100, Richard Guenther wrote:
> > I think we might get back some compile-time memory usage by constructing
> > the full names at debug output time.  If I remember correctly most of
> > the identifiers generated are for types that don't have their template
> > arguments fully substituted (so we won't see an instantiation of that
> > type or debug info).  But I might be wrong, as what happens there in
> > the C++ frontend is not entirely clear to me.
> Back with my garbage collection hat on from a few years ago... this
> would be good.
> Even better would be to generate and output them early; i.e. before we
> pass things off to the middle end / back end, we ought to know which
> types are needed for the debug info.  That prevents having to carry the
> full type trees around.  But that would be a big design change!
> A huge amount of memory is devoted to things that we shouldn't really
> need after lowering except for debug info, but we can't get rid of it.
> > Now, we might be able to conditionalize the patch as is on not
> > generating debug info - this way memory usage for the -O0 case will
> > drop from ~2.5GB to 350MB.  With -O0 -g it will again be ~2.5GB.
> > 
> > Does that sound like a reasonable approach until we fix all the
> > debug info issues?
> I haven't been following, but this is still pretty lousy - is there
> really no practical way to do this without 2.5GB?

If we construct the names at the point we do now and want to retain
the full names (and _all_ of them - we don't know at the point we
construct them if we're going to need them), no.

Of course if we change the way debug info is generated we can do
better.  If we manage to delay generating the names until we know
which of them we need we can probably also save generating some of them.

But I fear I'm lost in the maze leading from the current name
generation place to the middle-end.  As there is no place where
types go from the frontend to the middle-end (and unused types get
discarded) it's hard to delay generating the names and avoid
generating some of them.

Note that with the current way of name-generation using the
not-so-suitable-for-this-task diagnostic machinery we also spend
quite some compile-time on building the names (50% of -O0 compile time


Richard Guenther <>
Novell / SUSE Labs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]