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

[Steven Bosscher <s.bosscher@student.tudelft.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