From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31607 invoked by alias); 19 Apr 2006 15:32:34 -0000 Received: (qmail 31583 invoked by uid 48); 19 Apr 2006 15:32:31 -0000 Date: Wed, 19 Apr 2006 15:32:00 -0000 Message-ID: <20060419153231.31578.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/26854] Inordinate compile times on large routines In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "law at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-04/txt/msg01547.txt.bz2 List-Id: ------- Comment #4 from law at redhat dot com 2006-04-19 15:32 ------- OK, as expected, DOM was doing something totally stupid with immediate uses. On my x86 box I've got a patch which takes us from ~250 seconds in DOM to around 5. I'm going to get this fix bootstrapped and regression tested, then port it to mainline (where things are slightly different/rearranged, but the same core problem exists). Unfortunately, those gains are dwarfed by the wall-clock time burned swapping/paging due to memory usage in other passes. The worst memory offenders (in pain order) are: reorder blocks (possible given the number of blocks/edges in this code) expand (??? possibly being charged for some other passes time) global-alloc Mainline has a different memory pain profile -- the new RTL invariant code motion pass goes absolutely nuts memory-wise. I'm not planning to work on any of the memory consumption issues. -- law at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rakdver at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854