public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space Date: Sat, 19 Aug 2006 01:52:00 -0000 [thread overview] Message-ID: <20060819015144.10314.qmail@sourceware.org> (raw) In-Reply-To: <bug-28071-12846@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2006-08-19 1:52 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-06-17 9:27 [Bug c/28071] New: " raffalli at univ-savoie dot fr 2006-06-17 9:52 ` [Bug c/28071] " raffalli at univ-savoie dot fr 2006-06-17 10:57 ` steven at gcc dot gnu dot org 2006-06-17 11:06 ` steven at gcc dot gnu dot org 2006-06-17 14:30 ` steven at gcc dot gnu dot org 2006-06-17 14:56 ` [Bug middle-end/28071] [4.2 regression] " pinskia at gcc dot gnu dot org 2006-06-17 18:42 ` [Bug middle-end/28071] [4.1/4.2 " rguenth at gcc dot gnu dot org 2006-06-17 19:24 ` [Bug rtl-optimization/28071] " rguenth at gcc dot gnu dot org 2006-06-19 8:56 ` raffalli at univ-savoie dot fr 2006-07-17 2:45 ` mmitchel at gcc dot gnu dot org 2006-07-21 21:12 ` hubicka at gcc dot gnu dot org 2006-07-21 22:01 ` raffalli at univ-savoie dot fr 2006-07-22 13:47 ` hubicka at ucw dot cz 2006-07-22 17:13 ` hubicka at ucw dot cz 2006-07-22 18:09 ` hubicka at ucw dot cz 2006-07-22 19:30 ` hubicka at ucw dot cz 2006-07-22 20:51 ` Jan Hubicka 2006-07-22 20:51 ` hubicka at ucw dot cz 2006-07-24 0:05 ` patchapp at dberlin dot org 2006-07-24 11:24 ` hubicka at gcc dot gnu dot org 2006-07-24 11:28 ` hubicka at gcc dot gnu dot org 2006-07-24 11:54 ` hubicka at gcc dot gnu dot org 2006-07-25 18:20 ` patchapp at dberlin dot org 2006-07-26 22:52 ` hubicka at gcc dot gnu dot org 2006-07-27 7:15 ` patchapp at dberlin dot org 2006-07-27 7:20 ` patchapp at dberlin dot org 2006-07-27 7:25 ` patchapp at dberlin dot org 2006-07-27 8:00 ` patchapp at dberlin dot org 2006-07-27 16:02 ` hubicka at gcc dot gnu dot org 2006-07-27 16:03 ` hubicka at gcc dot gnu dot org 2006-07-27 17:10 ` hubicka at gcc dot gnu dot org 2006-07-28 9:30 ` patchapp at dberlin dot org 2006-07-28 9:41 ` hubicka at ucw dot cz 2006-07-29 13:15 ` hubicka at gcc dot gnu dot org 2006-07-30 5:45 ` patchapp at dberlin dot org 2006-08-11 7:17 ` ebotcazou at gcc dot gnu dot org 2006-08-16 21:25 ` [Bug middle-end/28071] " rakdver at gcc dot gnu dot org 2006-08-18 23:10 ` hubicka at ucw dot cz 2006-08-19 0:19 ` hubicka at ucw dot cz 2006-08-19 1:52 ` hubicka at ucw dot cz [this message] 2006-08-19 21:58 ` amacleod at redhat dot com 2006-08-20 0:58 ` Jan Hubicka 2006-08-20 0:59 ` hubicka at ucw dot cz 2006-08-21 0:00 ` hubicka at gcc dot gnu dot org 2006-08-21 1:42 ` hubicka at gcc dot gnu dot org 2006-08-21 2:59 ` Jan Hubicka 2006-08-21 2:59 ` hubicka at ucw dot cz 2006-08-21 12:56 ` hubicka at ucw dot cz 2006-08-21 17:11 ` hubicka at ucw dot cz 2006-08-25 1:37 ` amacleod at redhat dot com 2006-08-25 1:43 ` amacleod at redhat dot com 2006-08-25 1:57 ` amacleod at redhat dot com 2006-08-28 17:18 ` amacleod at gcc dot gnu dot org 2006-08-28 17:37 ` amacleod at redhat dot com 2006-09-12 10:11 ` hubicka at gcc dot gnu dot org 2006-09-23 9:44 ` steven at gcc dot gnu dot org 2006-09-23 10:22 ` [Bug middle-end/28071] [4.1 " rguenth at gcc dot gnu dot org 2007-01-10 11:43 ` mkuvyrkov at gcc dot gnu dot org 2007-01-15 7:19 ` zaks at il dot ibm dot com 2007-01-15 7:52 ` Maxim Kuvyrkov 2007-01-15 7:53 ` mkuvyrkov at ispras dot ru 2007-01-15 15:31 ` zaks at il dot ibm dot com 2007-01-18 9:52 ` hubicka at ucw dot cz 2007-02-06 22:05 ` hubicka at gcc dot gnu dot org 2007-02-06 22:15 ` hubicka at gcc dot gnu dot org 2007-03-26 15:50 ` bonzini at gnu dot org 2007-04-16 15:04 ` mkuvyrkov at gcc dot gnu dot org 2007-04-16 15:07 ` mkuvyrkov at gcc dot gnu dot org 2007-04-17 18:16 ` hubicka at gcc dot gnu dot org 2007-04-17 18:38 ` hubicka at ucw dot cz 2007-05-14 21:37 ` mmitchel at gcc dot gnu dot org 2007-05-14 21:49 ` fang at csl dot cornell dot edu 2007-07-20 3:47 ` mmitchel at gcc dot gnu dot org 2007-10-09 19:25 ` mmitchel at gcc dot gnu dot org 2007-11-03 8:07 ` ebotcazou at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20060819015144.10314.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).