From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12850 invoked by alias); 13 Dec 2010 13:22:58 -0000 Received: (qmail 12828 invoked by uid 22791); 13 Dec 2010 13:22:57 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM 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; Mon, 13 Dec 2010 13:22:52 +0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions 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: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: 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: Mon, 13 Dec 2010 13:22: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: 2010-12/txt/msg01403.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #11 from Jan Hubicka 2010-12-13 13:22:28 UTC --- Patched compiler at -O2 now shows: integration : 166.20 (16%) usr 0.19 ( 1%) sys 166.86 (15%) wall 92691 kB ( 4%) ggc tree CCP : 792.75 (74%) usr 0.15 ( 1%) sys 794.63 (73%) wall 66560 kB ( 3%) ggc integration is probably the overhead of splitting BBs, I wonder what makes tree CCP so slow, it is probably worth investigating. The profile shows: 2009425 73.3643 cc1 cc1 gsi_for_stmt 398058 14.5331 cc1 cc1 gimple_set_bb 22230 0.8116 libc-2.11.1.so libc-2.11.1.so _int_malloc 14339 0.5235 cc1 cc1 gimple_split_block 11727 0.4282 libc-2.11.1.so libc-2.11.1.so memset 10411 0.3801 libc-2.11.1.so libc-2.11.1.so _IO_vfscanf 9095 0.3321 cc1 cc1 htab_delete 6061 0.2213 cc1 cc1 bitmap_set_bit 5990 0.2187 no-vmlinux no-vmlinux /no-vmlinux 5912 0.2158 libc-2.11.1.so libc-2.11.1.so _int_free 5077 0.1854 libc-2.11.1.so libc-2.11.1.so malloc_consolidate 4516 0.1649 cc1 cc1 htab_find_slot_with_hash 4515 0.1648 opreport opreport /usr/bin/opreport 4284 0.1564 libc-2.11.1.so libc-2.11.1.so free 4234 0.1546 libc-2.11.1.so libc-2.11.1.so malloc 4106 0.1499 cc1 cc1 htab_traverse_noresize 3737 0.1364 libc-2.11.1.so libc-2.11.1.so calloc 3197 0.1167 cc1 cc1 eq_node 2996 0.1094 cc1 cc1 df_note_compute 2632 0.0961 cc1 cc1 ggc_internal_alloc_stat 2476 0.0904 cc1 cc1 bitmap_bit_p Other passes are sub 10s each. Maybe tree-ccp just gets the overhead of merging the large BBs into single? Honza