From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-34063-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8345 invoked by alias); 2 May 2003 19:16:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 8313 invoked by uid 71); 2 May 2003 19:16:00 -0000
Date: Fri, 02 May 2003 19:16:00 -0000
Message-ID: <20030502191600.8312.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
Subject: Re: optimization/10155: [3.3/3.4 regression] gcc -O2/-O3 uses excessive amount of memory
Reply-To: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
X-SW-Source: 2003-05/txt/msg00151.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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