From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11899 invoked by alias); 14 Feb 2009 21:58:26 -0000 Received: (qmail 11834 invoked by alias); 14 Feb 2009 21:58:11 -0000 Date: Sat, 14 Feb 2009 21:58:00 -0000 Message-ID: <20090214215811.11833.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "lucier at math dot purdue dot edu" 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: 2009-02/txt/msg01310.txt.bz2 ------- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58 ------- Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines I instrumented the compiler and looked how many nodes were in each loop processed by LICM for the Gambit runtime and compiler. For generated code, except for the "loop" that contained the entire function, the greatest number of nodes was 30. (Because computed gotos are used in the code that checks for heap and stack overflows after allocations and for waiting interrupts, it's hard to go long in Scheme code without hitting the "big loop".) For hand-written code, the greatest number of nodes in a loop was 123. When bootstrapping gcc with --enable-languages=c, the largest number of nodes in a loop was 803, and there were 12 loops detected that had over 500 nodes. 548 loops had 100 nodes or greater. (This is a bootstrap, so some files were compiled twice with the instrumented compiler.) So perhaps an -O1 default for LICM of 100 nodes is reasonable, or perhaps one might up it to 1000 just to catch everything "reasonable". Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854