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