From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16540 invoked by alias); 10 Apr 2002 17:42:25 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 16496 invoked by uid 61); 10 Apr 2002 17:42:23 -0000 Date: Wed, 10 Apr 2002 10:42:00 -0000 Message-ID: <20020410174223.16495.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, rth@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de From: rth@gcc.gnu.org Reply-To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, rth@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de, gcc-gnats@gcc.gnu.org Subject: Re: c++/5504: Optimization breaks wei-ku-1 from blitz X-SW-Source: 2002-04/txt/msg00589.txt.bz2 List-Id: Synopsis: Optimization breaks wei-ku-1 from blitz Responsible-Changed-From-To: jason->rth Responsible-Changed-By: rth Responsible-Changed-When: Wed Apr 10 10:42:22 2002 Responsible-Changed-Why: My patch. State-Changed-From-To: analyzed->suspended State-Changed-By: rth State-Changed-When: Wed Apr 10 10:42:22 2002 State-Changed-Why: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00474.html Given enough memory, this solves the compile-time problem. It now takes about 6 minutes to compile instead of 7 hours. Peak memory usage is still atrocious though -- abour 1.2GB; I'm not sure how to solve that, or indeed if it can be solved. EH semantics of goto requires that all of the EH regions be created so that we can bind vs other EH regions at the end. Even if we discover in the middle that there will be no such goto requiring such processing, we'll have already created the rtl, which means that the memory is already in use. Since we can't garbage collect in the middle of rtl generation, peak memory usage will not be impacted by any complex schemes in the middle of code generation. It may be possible to perform an optimization pass in which EH cleanups are removed from the AST before instantiation in rtl. That would indeed positively impact peak memory use. Put that in the indefinite future though... http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5504