This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessiveamount of memory
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 2 May 2003 11:06:01 -0000
- Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessiveamount of memory
- Reply-to: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
The following reply was made to PR optimization/10155; it has been noted by GNATS.
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: p.van-hoof@qub.ac.uk, gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org,
jh@suse.de
Cc:
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive
amount of memory
Date: Fri, 02 May 2003 12:58:47 +0200
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