[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #50 from Steven Bosscher 2011-12-02 13:06:12 UTC --- Michael, you were working on this. Did your patches resolve this bug completely by now?
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #51 from Michael Matz 2011-12-02 13:23:57 UTC --- Nope, I don't have more than a couple hacks to try different approaches as of right now. I should dust them off for next stage1.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Steven Bosscher changed: What|Removed |Added Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-05/msg01813.htm ||l --- Comment #52 from Steven Bosscher 2012-05-27 23:15:19 UTC --- Patch set posted by matz.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #53 from Joost VandeVondele 2012-05-29 07:45:36 UTC --- For the original testcase I have for trunk (gcc version 4.8.0 20120516 (experimental) [trunk revision 187595] (GCC)) very reasonable times (1min) at -O0, but pretty slow (20min) at -O2. At -O2, all time goes to 'alias stmt walking : 826.02' in the latter case. Time reports below: gfortran -ftime-report -ffree-line-length-512 -g -c testcase.f90 Execution times (seconds) phase setup : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 243 kB ( 0%) ggc phase parsing : 3.59 ( 6%) usr 0.05 ( 5%) sys 3.64 ( 6%) wall 47592 kB ( 7%) ggc phase cgraph: 60.02 (94%) usr 0.90 (95%) sys 60.94 (94%) wall 649547 kB (93%) ggc phase generate : 60.03 (94%) usr 0.90 (95%) sys 60.95 (94%) wall 649948 kB (93%) ggc garbage collection : 1.04 ( 2%) usr 0.00 ( 0%) sys 1.04 ( 2%) wall 0 kB ( 0%) ggc callgraph construction : 0.18 ( 0%) usr 0.01 ( 1%) sys 0.20 ( 0%) wall 15909 kB ( 2%) ggc callgraph optimization : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 201 kB ( 0%) ggc cfg construction: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 7 kB ( 0%) ggc cfg cleanup : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc CFG verifier: 1.16 ( 2%) usr 0.00 ( 0%) sys 1.18 ( 2%) wall 0 kB ( 0%) ggc trivially dead code : 0.34 ( 1%) usr 0.00 ( 0%) sys 0.35 ( 1%) wall 0 kB ( 0%) ggc df scan insns : 1.00 ( 2%) usr 0.25 (26%) sys 1.23 ( 2%) wall 11 kB ( 0%) ggc df live regs: 0.46 ( 1%) usr 0.00 ( 0%) sys 0.49 ( 1%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.45 ( 1%) usr 0.01 ( 1%) sys 0.47 ( 1%) wall 19416 kB ( 3%) ggc register information: 0.20 ( 0%) usr 0.01 ( 1%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 8336 kB ( 1%) ggc rebuild jump labels : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc parser (global) : 3.59 ( 6%) usr 0.05 ( 5%) sys 3.64 ( 6%) wall 47587 kB ( 7%) ggc inline heuristics : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 54 kB ( 0%) ggc tree gimplify : 0.48 ( 1%) usr 0.01 ( 1%) sys 0.49 ( 1%) wall 26304 kB ( 4%) ggc tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 39 kB ( 0%) ggc tree CFG construction : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 190 kB ( 0%) ggc tree find ref. vars : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 3263 kB ( 0%) ggc tree PHI insertion : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 43 kB ( 0%) ggc tree SSA other : 0.04 ( 0%) usr 0.02 ( 2%) sys 0.01 ( 0%) wall 18 kB ( 0%) ggc tree operand scan : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.06 ( 0%) wall 118 kB ( 0%) ggc tree SSA verifier : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc tree STMT verifier : 0.58 ( 1%) usr 0.06 ( 6%) sys 0.62 ( 1%) wall 0 kB ( 0%) ggc callgraph verifier : 0.28 ( 0%) usr 0.00 ( 0%) sys 0.29 ( 0%) wall 0 kB ( 0%) ggc out of ssa : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc expand vars : 21.72 (34%) usr 0.02 ( 2%) sys 21.74 (34%) wall 10086 kB ( 1%) ggc expand : 6.18 (10%) usr 0.15 (16%) sys 6.31 (10%) wall 251886 kB (36%) ggc post expand cleanups: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 1744 kB ( 0%) ggc integrated RA : 10.75 (17%) usr 0.16 (17%) sys 10.87 (17%) wall 128826 kB (18%) ggc reload : 5.72 ( 9%) usr 0.15 (16%) sys 5.92 ( 9%) wall 123587 kB (18%) ggc thread pro- & epilogue : 2.51 ( 4%) usr 0.00 ( 0%) sys 2.50 ( 4%) wall 198 kB ( 0%) ggc machine dep reorg : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc final : 2.61 ( 4%) usr 0.04 ( 4%) sys 2.65 ( 4%) wall 7227 kB ( 1%) ggc symout : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 4914 kB ( 1%) ggc rest of compilation : 2.36 ( 4%) usr 0.00 ( 0%) sys 2.35 ( 4%) wall 47578 kB ( 7%) ggc verify RTL sharing : 1.02 ( 2%) usr 0.00 ( 0%) sys 1.04 ( 2%) wall 0 kB ( 0%) ggc TOTAL : 63.65 0.9564.62 697784 kB gfortran -ftime-report -ffree-line-length-512 -O2 -g -c testcase.f90 Execution times (seconds) phase setup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 243 kB ( 0%) ggc phase parsin
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #54 from Michael Matz 2012-05-29 12:47:29 UTC --- Yes, only the expand vars problem is attacked by my patch. The alias walking seems to come from an IPA analysis via ipa_compute_jump_functions. detect_type_change uses the walker from all call statements, and that's used by compute_known_type_jump_func, from compute_scalar_jump_functions, from ipa_compute_jump_functions_for_edge. And the latter is called for each callee. The yukawa_gn_full function has very many calls, so this seems to make out for an quadratic problem.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #55 from Michael Matz 2012-05-29 13:08:52 UTC --- FWIW the node->callees list in yukawa_gn_full has 25076 entries.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Jan Hubicka changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #56 from Jan Hubicka 2012-05-29 14:57:30 UTC --- That functions is Martin's. Martin, can you please take a look?
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #57 from Martin Jambor 2012-05-29 15:08:39 UTC --- (In reply to comment #56) > That functions is Martin's. Martin, can you please take a look? I will, on Monday.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #58 from Michael Matz 2012-06-15 14:56:33 UTC --- Author: matz Date: Fri Jun 15 14:56:26 2012 New Revision: 188667 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188667 Log: PR middle-end/38474 * cfgexpand.c (add_alias_set_conflicts): Remove. (expand_used_vars): Don't call it. (aggregate_contains_union_type): Remove. * function.c (n_temp_slots_in_use): New static data. (make_slot_available, assign_stack_temp_for_type): Update it. (init_temp_slots): Zero it. (remove_unused_temp_slot_addresses): Use it for quicker removal. (remove_unused_temp_slot_addresses_1): Use htab_clear_slot. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/function.c
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #59 from Michael Matz 2012-06-15 15:12:59 UTC --- There should be no compile performance problems in expand anymore. The alias stmt walker as used from IPA remains a problem, though.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #60 from Joost VandeVondele 2012-06-15 15:26:20 UTC --- (In reply to comment #59) > There should be no compile performance problems in expand anymore. > The alias stmt walker as used from IPA remains a problem, though. Thanks... expand is now indeed essentially gone from the timing report. > gfortran -ftime-report -ffree-line-length-512 -g -c testcase.f90 Execution times (seconds) phase setup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 243 kB ( 0%) ggc phase parsing : 3.57 ( 9%) usr 0.06 ( 7%) sys 3.63 ( 9%) wall 47592 kB ( 7%) ggc phase cgraph: 36.49 (91%) usr 0.86 (93%) sys 37.34 (91%) wall 647436 kB (93%) ggc phase generate : 36.50 (91%) usr 0.86 (93%) sys 37.36 (91%) wall 647838 kB (93%) ggc garbage collection : 1.04 ( 3%) usr 0.00 ( 0%) sys 1.04 ( 3%) wall 0 kB ( 0%) ggc callgraph construction : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 15909 kB ( 2%) ggc callgraph optimization : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 201 kB ( 0%) ggc cfg construction: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 7 kB ( 0%) ggc cfg cleanup : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc CFG verifier: 1.26 ( 3%) usr 0.00 ( 0%) sys 1.25 ( 3%) wall 0 kB ( 0%) ggc trivially dead code : 0.43 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 1%) wall 0 kB ( 0%) ggc df scan insns : 0.98 ( 2%) usr 0.24 (26%) sys 1.24 ( 3%) wall 11 kB ( 0%) ggc df live regs: 0.58 ( 1%) usr 0.01 ( 1%) sys 0.57 ( 1%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.43 ( 1%) usr 0.01 ( 1%) sys 0.45 ( 1%) wall 19416 kB ( 3%) ggc register information: 0.18 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 8337 kB ( 1%) ggc rebuild jump labels : 0.22 ( 1%) usr 0.00 ( 0%) sys 0.21 ( 1%) wall 0 kB ( 0%) ggc parser (global) : 3.57 ( 9%) usr 0.06 ( 7%) sys 3.63 ( 9%) wall 47587 kB ( 7%) ggc inline heuristics : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 54 kB ( 0%) ggc tree gimplify : 0.51 ( 1%) usr 0.01 ( 1%) sys 0.51 ( 1%) wall 26304 kB ( 4%) ggc tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 39 kB ( 0%) ggc tree CFG construction : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 190 kB ( 0%) ggc tree CFG cleanup: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3263 kB ( 0%) ggc tree PHI insertion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA other : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.02 ( 0%) wall 18 kB ( 0%) ggc tree operand scan : 0.03 ( 0%) usr 0.03 ( 3%) sys 0.05 ( 0%) wall 118 kB ( 0%) ggc tree SSA verifier : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree STMT verifier : 0.56 ( 1%) usr 0.05 ( 5%) sys 0.63 ( 2%) wall 0 kB ( 0%) ggc callgraph verifier : 0.25 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall 0 kB ( 0%) ggc out of ssa : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc expand vars : 1.02 ( 3%) usr 0.02 ( 2%) sys 1.03 ( 3%) wall 10086 kB ( 1%) ggc expand : 2.03 ( 5%) usr 0.12 (13%) sys 2.18 ( 5%) wall 249774 kB (36%) ggc post expand cleanups: 0.14 ( 0%) usr 0.01 ( 1%) sys 0.14 ( 0%) wall 1744 kB ( 0%) ggc integrated RA : 10.75 (27%) usr 0.15 (16%) sys 10.93 (27%) wall 128826 kB (19%) ggc reload : 5.56 (14%) usr 0.16 (17%) sys 5.77 (14%) wall 123587 kB (18%) ggc thread pro- & epilogue : 2.65 ( 7%) usr 0.00 ( 0%) sys 2.64 ( 6%) wall 198 kB ( 0%) ggc machine dep reorg : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc final : 3.11 ( 8%) usr 0.04 ( 4%) sys 3.15 ( 8%) wall 7227 kB ( 1%) ggc symout : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 4914 kB ( 1%) ggc rest of compilation : 2.46 ( 6%) usr 0.00 ( 0%) sys 2.39 ( 6%) wall 47578 kB ( 7%) ggc unaccounted todo: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc verify RTL sharing : 1.49 ( 4%) usr 0.00 ( 0%) sys 1.48 ( 4%) wall 0 kB ( 0%) ggc TOTAL : 40.09 0.9241.02 695674 kB
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #61 from Martin Jambor 2012-06-26 14:26:34 UTC --- (In reply to comment #57) > > I will, on Monday. And by Monday I obviously meant yesterday ;-) Anyway, on the machine where are debugged this, compilation at -O3 took over 16 seconds which dropped to about 13.5 seconds when I also added -fno-devirtualize (-ftime-report showed that alias stmt walking dropped from 82% to 75%). This is mainly due to calls to detect_type_change from compute_known_type_jump_func, there are 36454 of them and all are of course completely pointless because we do not devirtualize in Fortran. Looking into the code, it is apparent that I even attempted to avoid such situations but somehow was not paying enough attention. The rather obvious patch below fixes that. With it, the compile time at -O3 drops to 13.5 without any additional options (~50 calls to detect_type_change_ssa and detect_type change from other places remain but those are not a big problem here, they are not so easy to get rid of and I hope to eventually remove the type detection machinery from IPA altogether so I'll keep those for later). I'll bootstrap and test the patch and post it to the mailing list soon. Index: gcc/ipa-prop.c === --- gcc/ipa-prop.c (revision 188931) +++ gcc/ipa-prop.c (working copy) @@ -912,8 +912,8 @@ compute_known_type_jump_func (tree op, s || is_global_var (base)) return; - if (detect_type_change (op, base, call, jfunc, offset) - || !TYPE_BINFO (TREE_TYPE (base))) + if (!TYPE_BINFO (TREE_TYPE (base)) + || detect_type_change (op, base, call, jfunc, offset)) return;
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #62 from Michael Matz 2012-06-26 14:44:58 UTC --- (In reply to comment #61) > (In reply to comment #57) > > Anyway, on the machine where are debugged this, compilation at -O3 > took over 16 seconds which dropped to about 13.5 seconds when I also What? Must be a future machine. On everything I have access to the reduced testcase (6309 lines) takes about 800 to 1000 seconds. Do you build without any checking? In any case, the proposed patch does reduce the time to basically nothing for the alias tree walker, so: thanks :)
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #63 from Richard Guenther 2012-06-26 14:58:31 UTC --- (In reply to comment #61) > (In reply to comment #57) > > > > I will, on Monday. > > And by Monday I obviously meant yesterday ;-) > > Anyway, on the machine where are debugged this, compilation at -O3 > took over 16 seconds which dropped to about 13.5 seconds when I also > added -fno-devirtualize (-ftime-report showed that alias stmt walking > dropped from 82% to 75%). This is mainly due to calls to > detect_type_change from compute_known_type_jump_func, there are 36454 > of them and all are of course completely pointless because we do not > devirtualize in Fortran. > > Looking into the code, it is apparent that I even attempted to avoid > such situations but somehow was not paying enough attention. The > rather obvious patch below fixes that. With it, the compile time at > -O3 drops to 13.5 without any additional options (~50 calls to > detect_type_change_ssa and detect_type change from other places remain > but those are not a big problem here, they are not so easy to get rid > of and I hope to eventually remove the type detection machinery from > IPA altogether so I'll keep those for later). > > I'll bootstrap and test the patch and post it to the mailing list > soon. > > Index: gcc/ipa-prop.c > === > --- gcc/ipa-prop.c (revision 188931) > +++ gcc/ipa-prop.c (working copy) > @@ -912,8 +912,8 @@ compute_known_type_jump_func (tree op, s >|| is_global_var (base)) > return; > > - if (detect_type_change (op, base, call, jfunc, offset) > - || !TYPE_BINFO (TREE_TYPE (base))) > + if (!TYPE_BINFO (TREE_TYPE (base)) > + || detect_type_change (op, base, call, jfunc, offset)) > return; That change qualifies for a backport to all branches it applies to ...
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #64 from Martin Jambor 2012-06-26 15:01:28 UTC --- (In reply to comment #62) > (In reply to comment #61) > > (In reply to comment #57) > > > > Anyway, on the machine where are debugged this, compilation at -O3 > > took over 16 seconds which dropped to about 13.5 seconds when I also > > What? Must be a future machine. On everything I have access to the reduced > testcase (6309 lines) takes about 800 to 1000 seconds. Do you build without > any checking? Minutes! Of course I meant minutes, the drop is thus from ~1000 seconds to ~810 seconds. I forgot I was using bash time instead of /usr/bin/time -f%U which I was regularly using only a few days ago. > > In any case, the proposed patch does reduce the time to basically nothing for > the alias tree walker, so: thanks :) I've experimentally disabled the walker in is_parm_modified_before_stmt and am now waiting for results but I guess it won't have any measurable impact.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #65 from Martin Jambor 2012-06-29 14:34:34 UTC --- I have posted the patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01928.html along with an equivalent one for the 4.6 branch: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01929.html
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #66 from Martin Jambor 2012-07-02 15:28:17 UTC --- Author: jamborm Date: Mon Jul 2 15:28:11 2012 New Revision: 189163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189163 Log: 2012-07-02 Martin Jambor PR middle-end/38474 * ipa-prop.c (compute_known_type_jump_func): Put BINFO check before a dynamic type change check. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #67 from Martin Jambor 2012-07-02 15:44:01 UTC --- Author: jamborm Date: Mon Jul 2 15:43:56 2012 New Revision: 189164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189164 Log: 2012-07-02 Martin Jambor PR middle-end/38474 * ipa-prop.c (compute_known_type_jump_func): Put BINFO check before a dynamic type change check. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/ipa-prop.c
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #68 from Martin Jambor 2012-07-02 15:53:29 UTC --- Author: jamborm Date: Mon Jul 2 15:53:21 2012 New Revision: 189165 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189165 Log: 2012-07-02 Martin Jambor PR middle-end/38474 * ipa-prop.c (compute_known_type_jump_func): Check for a BINFO before checking for a dynamic type change. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/ipa-prop.c
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Richard Guenther changed: What|Removed |Added Target Milestone|4.3.6 |---
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
--- Comment #49 from steven at gcc dot gnu dot org 2010-05-23 21:02 --- Let's change the bug type at least, from a meta bug to a normal bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[Meta] slow compilation at -|slow compilation at -O0 due |O0 (callgraph optimization, |to expand's temp slot goo |inline heuristics, expand ) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Steven Bosscher changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #69 from Steven Bosscher 2012-08-28 08:25:06 UTC --- Is there still a problem here?
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #70 from Joost VandeVondele 2012-08-28 11:28:06 UTC --- (In reply to comment #69) > Is there still a problem here? for current trunk and the original testcase, timings are reasonable at -O0 -O1 -O2, but very long at -O3 (>60min): report.O0.txt: TOTAL : 38.78 0.8939.67 691166 kB report.O1.txt: TOTAL : 70.04 1.1371.22 634523 kB report.O2.txt: TOTAL : 204.51 1.16 205.71 691522 kB the biggest consumers are -O0: integrated RA : 10.36 reload : 5.16; -O1: tree PTA: 7.77 integrated RA : 13.36 -O2: expand vars : 83.15 tree PTA: 35.04 -O3: (also needs about 4Gb of memory) ??? not yet finished (>60min)
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #71 from Joost VandeVondele 2012-08-28 14:54:54 UTC --- The -O3 compile is 3h later still running and needs >20Gb of RAM. The issue seems now to be variable_tracking_main #0 0x00b7b8ce in dataflow_set_preserve_mem_locs(void**, void*) () #1 0x00e76168 in htab_traverse_noresize () #2 0x00b770e0 in dataflow_set_clear_at_call(dataflow_set_def*) () #3 0x00b7c613 in vt_emit_notes() () #4 0x00b847ea in variable_tracking_main() () #5 0x008e8acf in execute_one_pass(opt_pass*) ()
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Steven Bosscher changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #72 from Steven Bosscher 2012-08-28 15:06:56 UTC --- Thus, another var-tracking issue.
