From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11001 invoked by alias); 19 Aug 2006 01:52:37 -0000 Received: (qmail 10315 invoked by alias); 19 Aug 2006 01:51:44 -0000 Date: Sat, 19 Aug 2006 01:52:00 -0000 Message-ID: <20060819015144.10314.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at ucw dot cz" 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-08/txt/msg01495.txt.bz2 List-Id: ------- Comment #39 from hubicka at ucw dot cz 2006-08-19 01:51 ------- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space The -O1 time sinks: life analysis : 25.44 (19%) usr 0.00 ( 0%) sys 25.49 (17%) wall 2565 kB ( 2%) ggc inline heuristics : 14.92 (11%) usr 0.00 ( 0%) sys 14.95 (10%) wall 1486 kB ( 1%) ggc integration : 20.73 (15%) usr 0.10 ( 4%) sys 22.72 (15%) wall 33445 kB (20%) ggc tree SSA to normal : 27.97 (20%) usr 0.04 ( 2%) sys 28.13 (19%) wall 17 kB ( 0%) ggc expand : 2.56 ( 2%) usr 0.04 ( 2%) sys 2.67 ( 2%) wall 24100 kB (14%) ggc local alloc : 7.21 ( 5%) usr 0.03 ( 1%) sys 7.18 ( 5%) wall 1855 kB ( 1%) ggc global alloc : 11.76 ( 9%) usr 0.99 (39%) sys 17.71 (12%) wall 11029 kB ( 6%) ggc reload CSE regs : 7.91 ( 6%) usr 0.02 ( 1%) sys 7.97 ( 5%) wall 2393 kB ( 1%) ggc TOTAL : 136.62 2.56 148.01 170448 kB tree SSA to normal spends most of time in find_value_in_list because TER is shuffling around single linked lists in the quadratic way. I got quickly lost in the logic there. Andrew, can you take a look, please? integration runs into qudratic behaviour of cgraph_edge. Implementing hashtable for large cgraphs is easy, I will do so. Also tree_split_block quadratic behaviour hits us here. reload CSE regs has hard time to track all the stack slot memory locations. It is working harder than needed because a lot of memories are believed to be aliasing even if theoretically almost everything SRA and has no address taken so it should have unique alias sets. Life analysis spends most of time in dead store removal code. Again lowering --param might help. I am also testing little patch to cut it to 13 seconds by speeding up reg_overlap_mentioned_p. It would be insteresting to see how dataflow branch score here. inline heuristics spends most time checking inline_function_growth limit, I will need to think about it a bit. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071