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

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

[Peter van Hoof]

The following reply was made to PR optimization/10155; it has been noted by GNATS.

From: Peter van Hoof <p.van-hoof@qub.ac.uk>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, jh@suse.de, 
    rakdver@atrey.karlin.mff.cuni.cz
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive
         amount of memory
Date: Tue, 06 May 2003 21:41:00 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10155
 
 
 > 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.
 > 
 > Peter, 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?
 
 Now that my computer is back in the land of the living, I can finally answer 
 this (in case it is still relevant)... I ran the initial test case on a Sun 
 Blade 100 with 2GB of RAM, these are the settings with this machine:
 
 GNU C version 3.4 20030504 (experimental) (sparc-sun-solaris2.9)
 	compiled by GNU C version 3.4 20030504 (experimental).
 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 
 The compiler reaches a maximum size of 1894MB, which means that the machine has 
 to swap out some other processes. I also have an Ultra 5 with 640MB of RAM, 
 these are the settings on that machine
 
 GGC heuristics: --param ggc-min-expand=73 --param ggc-min-heapsize=81920
 
 I killed the compilation when the compiler grew to >1700MB because swap space 
 was running dangerously low, i.e. on this machine the compiler would use up all 
 the swap space it could get its hands on.
 
 
 Hope this helps...
 
 Peter.
 

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

[Zdenek Dvorak]

The following reply was made to PR optimization/10155; it has been noted by GNATS.

From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: Jan Hubicka <jh@suse.cz>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>,
	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
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 21:08:49 +0200

 Hello,
 
 > > 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.
 > > 
 > > 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
 > Zdenek, this really ought not to happen, what is going on?
 
 it is just too many loops; the unswitching takes in fact almost no
 time (there is nothing to unswitch at all) -- all the time increase
 you see is in verify_loop_structure (it exhibits quadratic behavior
 on this kind of tests) and verify_dominators, so I guess there is not much
 to worry about.
 
 Zdenek

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

[Zdenek Dvorak]

The following reply was made to PR optimization/10155; it has been noted by GNATS.

From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: Jan Hubicka <jh@suse.cz>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>,
	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
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 19:38:39 +0200

 Hello,
 
 > > 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.
 > > 
 > > 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
 > Zdenek, this really ought not to happen, what is going on?
 
 I haven't tested the loop optimizer against a program consisting
 from several thousand 3-line loops, so I am not that much surprised
 that something went wrong. I will check where is the problem.
 
 Zdenek
 
 > > 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.
 > 
 > It should be more problem of inlining heuristics, than unit-at-a-time
 > (ie unit-at-a-time enables more inlining oppurtunities but it is
 > inlining heuristic mistake to take so many of them).
 > Or perhaps we manage to flatten functions called once into one
 > extraordinarily large function body and give up on it.  I will try to
 > investigate it, but my current priority is to get unit-at-a-time working
 > on C++.  Fixing this testcase should be easy then :)
 > 
 > Honza
 > > 
 > > Greetz
 > > Steven
 > > 
 > > 

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

[Jan Hubicka]

The following reply was made to PR optimization/10155; it has been noted by GNATS.

From: Jan Hubicka <jh@suse.cz>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: 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, rakdver@atrey.karlin.mff.cuni.cz
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Date: Fri, 2 May 2003 15:25:16 +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.
 > 
 > 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
 Zdenek, this really ought not to happen, what is going on?
 > 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.
 
 It should be more problem of inlining heuristics, than unit-at-a-time
 (ie unit-at-a-time enables more inlining oppurtunities but it is
 inlining heuristic mistake to take so many of them).
 Or perhaps we manage to flatten functions called once into one
 extraordinarily large function body and give up on it.  I will try to
 investigate it, but my current priority is to get unit-at-a-time working
 on C++.  Fixing this testcase should be easy then :)
 
 Honza
 > 
 > Greetz
 > Steven
 > 
 > 

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

[Steven Bosscher]

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
 
 
 

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

[ebotcazou]

Old Synopsis: [SPARC] gcc -O3 uses excessive amount of memory
New Synopsis: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory

State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Tue Apr 15 08:51:49 2003
State-Changed-Why:
    This is not specific to Sparc. Here are my results on x86:
    
    options     |   gcc -S -O2   |  gcc -S -O3
    ------------------------------------------
    gcc 3.2.3   |        13 MB   |       14 MB
    gcc 3.3     |        44 MB   |       48 MB
    gcc 3.4     |        52 MB   |    > 400 MB

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