A recent patch increased GCC's memory consumption!

Jan Hubicka jh@suse.cz
Sun Jul 17 11:52:00 GMT 2005


> On Sun, 17 Jul 2005, Jan Hubicka wrote:
> 
> > Also note the difference in between O2 and O3 results.  O2 seems to
> > increase memory usage in non-GGC only that might be register allocator
> > or something, but O3 seems to just inline more.  I am having very little
> > time to look into it today, so just wild guess, but can your patch affect
> > inlining decisions?
> 
> If having identical bit-field types in place of different ones (and so 
> e.g. not having conversions between them) affects the optimizers in any 
> way (e.g. if a conversion between two types of the same width is 
> considered to affect function size), it could affect inlining.  The 

NOP_EXPR/CONVERT_EXPR are considered to have size 0 for inlining
estimated but obviously there must be something else changing the
estimated, so we might just have sort of bad luck at -O3 level, still
don't know what happens at -O2 level.
Number of RTL instructions produced is about the same (1747600 after,
wrt 1746800 before) and number of registers differs just by 2 that
probably kills the explanation that regalloc might be responsible for
change of memory footprint....

> changes shouldn't affect code generation, so finding the first place code 
> generation changes between the before and after compilers might help.

What exactly you mean by code generation?  Apparently the gimple is
different in a way that there are fewer conversions that in turn changes
optimizer decisions, right?  So both RTL and gimple should be
different...

Honza
> 
> -- 
> Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
>     jsm@polyomino.org.uk (personal mail)
>     joseph@codesourcery.com (CodeSourcery mail)
>     jsm28@gcc.gnu.org (Bugzilla assignments and CCs)



More information about the Gcc-regression mailing list