This is the mail archive of the gcc@gcc.gnu.org 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]

Re: (C++) High memory usage with templates




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++




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