From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17208 invoked by alias); 9 Jan 2008 09:46:14 -0000 Received: (qmail 17005 invoked by alias); 9 Jan 2008 09:45:32 -0000 Date: Wed, 09 Jan 2008 10:32:00 -0000 Message-ID: <20080109094532.17004.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00842.txt.bz2 ------- Comment #37 from rguenther at suse dot de 2008-01-09 09:45 ------- Subject: Re: [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis On Wed, 9 Jan 2008, jaydub66 at gmail dot com wrote: > ------- Comment #36 from jaydub66 at gmail dot com 2008-01-09 09:38 ------- > > > How does the trunk compare now to the numbers mentioned in comment #16 ? > > Compiling with rev. 131414 gives: > > -O1 -fstrict-aliasing: 33sec, 438197 kB > -O2: 97sec, 669637 kB > -O3: 50sec, 392669 kB > > This is of course better than a few days ago (thanks to Richard's patches). But > it's not even close to the numbers in comment #16. > > What worries me about this is not the 33sec compile time (I could live with > that, if I'd have to), but the really large amount of memory. On a machine with > only 256MB compiling takes several minutes, due to massive swapping. > > Richard: > You said that the remaining issue is probably not gonna be fixed for 4.3. I > don't quite see the reason for this, since this apparently *was* fixed at some > point in the 4.3 trunk (see comment 16). Yeah, but we won't trade wrong-code bugs for better compile-time here. I have no idea how practical it is to fix basic-block duplication code (which is the worst offender regarding compile-time in this circumstances of too many VOPs). > Also this would really be a shame since it would make GCC 4.3 practically > unusable for our project (http://gibuu.physik.uni-giessen.de/GiBUU/). There is a workaround available - you can use --param max-fields-for-field-sensitive=0 to disable SFTs, but this may disable useful optimization. This is the route we want to go with 4.4, addressing the missed optimizations in different ways. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683