Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessiveamount of memory

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155

How much of this can be explained with Kaveh's physmem
patch?  IIRC that patch is not in 3.2,  and the increase
in memory consumption at -O2 may be a result of that
patch.

It looks like it's related to the amount of RAM in your
box.  For me, GCC -O2 never consumes more than 40MB, and
my machine has 192MB.  If your system pulls it off to
keep cc1 alive up to 1772MB, then I suppose you have at
least four times as much, so your GC param settings will
be much larger than mine --> GCC eats more memory.  That
_should_ give you a nice speedup over older GCC 3.x...
So perhaps we can change the synopsis to reflect that his
really only is a bug with -O3.

Paul, if you compile with "gcc -v", you can see your
garbage collector parameter settings.  For me they are:
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23891

Can you show us your settings?

The increase in memory at -O3 is a result of unit at a
time compilation (which is why I CC you, Honza).  You
can check that by compiling with -O2 + all flags enabled
at -O3 except -funit-at-a-time:

./cc1 10155.c -quiet -ftime-report -O2
TOTAL                 :  24.74             0.74            26.24

./cc1 10155.c -quiet -ftime-report -O2 -funswitch-loops 
-frename-registers -finline-functions
TOTAL                 :  31.49             0.59            33.87

Loop unswitching is responsible for most of the compile
time increase.
Now add -funit-at-a-time, and kabooooom! you lose.

Apparently unit-at-a-time should still honor some size
constraints, and it does not in its current form.

Greetz
Steven