From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22544 invoked by alias); 18 Jan 2011 14:49:15 -0000 Received: (qmail 22484 invoked by uid 22791); 18 Jan 2011 14:49:14 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Jan 2011 14:49:10 +0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/26854] Inordinate compile times on large routines X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 18 Jan 2011 15:08:00 -0000 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: 2011-01/txt/msg01800.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 Jan Hubicka changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #122 from Jan Hubicka 2011-01-18 14:48:32 UTC --- oprofiling shows that 50% of parsing time is in decl_jump_unsafe that is C frontend thingy to output some sort of warnings on gotos to VLAs. This can probably be solved quite easilly. Later we get (at -O2 all.i) 83417 17.0179 cc1 dominated_by_p 75164 15.3342 cc1 bitmap_equal_p 38134 7.7797 cc1 bitmap_set_bit 26144 5.3336 cc1 bitmap_ior_into 21031 4.2905 cc1 decl_jump_unsafe 16142 3.2931 cc1 register_new_assert_for.isra.42 12713 2.5936 cc1 bitmap_elt_insert_after 11136 2.2719 cc1 sbitmap_a_or_b 10625 2.1676 cc1 et_splay 10059 2.0521 cc1 walk_dominator_tree 6775 1.3822 cc1 dse_enter_block 5952 1.2143 cc1 bitmap_bit_p probably callgrinding to work out who is doing so many dominance tests might be enlightening. I get 5.3GB memory use at that point. 300MB of it seems to be GGC. Later in RTL copmilation DCE seems to get stuck... 62815 22.8048 cc1 mark_insn 40748 14.7934 cc1 rest_of_handle_ud_dce 18558 6.7374 cc1 bitmap_and_into 13046 4.7363 cc1 bitmap_elt_insert_after 9955 3.6141 cc1 bitmap_copy 8812 3.1992 cc1 bitmap_ior_into 7271 2.6397 cc1 bitmap_set_bit 6952 2.5239 cc1 bitmap_ior_and_compl 6718 2.4389 cc1 ira_compress_allocno_live_ranges 6370 2.3126 cc1 create_start_finish_chains 6123 2.2229 cc1 bitmap_and 4627 1.6798 cc1 bitmap_and_compl_into 3688 1.3389 cc1 regstat_compute_ri 3150 1.1436 cc1 record_reg_classes.constprop.9 Finally at IRA time we get stuck in 168451 33.5060 cc1 ira_build_conflicts 46025 9.1547 cc1 allocno_spill_priority_compare 18558 3.6913 cc1 bitmap_and_into 13046 2.5949 cc1 bitmap_elt_insert_after 12285 2.4436 cc1 color_pass 9955 1.9801 cc1 bitmap_copy 8812 1.7528 cc1 bitmap_ior_into 7689 1.5294 cc1 splay_tree_splay