This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (C++) High memory usage with templates
- To: law at cygnus dot com
- Subject: Re: (C++) High memory usage with templates
- From: joel at OARcorp dot com
- Date: Thu, 3 Dec 1998 16:28:38 -0600 (CST)
- cc: Steinar Bang <sb at metis dot no>, egcs at cygnus dot com
On Thu, 3 Dec 1998, Jeffrey A Law wrote:
>
> In message <Pine.LNX.3.96.981203072754.204E-100000@oar3remote.oarcorp.com>you
> write:
> > I don't know if it is relevant but there are a couple of files in the
> > powerpc simulator included with gdb that are (AFAIK) plain C that take an
> > enormous amount of resources to compile. I have seen a Linux box with 256
> > Mbytes RAM thrash trying to compile this file with optimization on. This
> > occurs when you configure psim to --enable-sim-inline. Perhaps this
> > indicates a problem that is not entirely C++ specific. Someone more
> > knowledgeable about psim and gcc can tell me if I am way off base here.
> When a function is declared inlined, the entire internal representation for the
> function is saved for integration into callers.
>
> When -finline-functions is in effect (including -O3), then *every* function's
> internal representation is saved. That alone costs a lot of memory.
>
> When integration occurs, the resulting code is also much larger, with many more
> expressions/registers/insns. This in turn causes a significant increase in the
> amount of memory to compile a particular function. Particularly since some
> of the data structuers are 2X based on insns, regs or whatever. And gcc tries
> just as hard to optimize big functions as little ones... So it does not say
> "gee, this is a big function, maybe I shouldn't do optimization xyz..."
>
> I looked at one case not long ago where the tables & bitmaps to implement
> global cse alone were 200+ meg for a heavily inlined/templated hunk of code.
This sounds like exactly what happens with psim. The routine in question
(if I recall correctly) is the instruction decoder. So when all the
instruction functionality is inlined, it gets quite large. I suppose
there is little that can be done about it but it does show that this type
of problem is not specific to C++