public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor @ 2005-08-19 22:48 falk at debian dot org 2005-08-19 23:03 ` [Bug rtl-optimization/23490] " pinskia at gcc dot gnu dot org ` (7 more replies) 0 siblings, 8 replies; 14+ messages in thread From: falk at debian dot org @ 2005-08-19 22:48 UTC (permalink / raw) To: gcc-bugs GNU C++ version 4.1.0 20050810 This little program: struct qd_real { double x[4]; inline qd_real(double x0, double x1, double x2, double x3) { x[0] = x0; x[1] = x1; x[2] = x2; x[3] = x3; } }; #define TWO(x) x, x const qd_real sin_table[] = { TWO( TWO( TWO( TWO( TWO( TWO( TWO( TWO( TWO( TWO( qd_real(1, 2, 3, 4) )))))))))) }; takes about 25 seconds to compile on my machine, although it's only 1000 lines or so. Compile time seems to scale roughly linear, but it's pretty damn slow. 2.95 takes 6 seconds, but that's without checking, so it's not entirely fair. Profile: samples % symbol name 3483 14.2530 rtx_equal_for_memref_p 2016 8.2498 find_base_term 1765 7.2227 canon_rtx 1493 6.1096 memrefs_conflict_p 1189 4.8656 for_each_rtx_1 1052 4.3049 nonoverlapping_memrefs_p 921 3.7689 rtx_equal_p 690 2.8236 exp_equiv_p 640 2.6190 addr_side_effect_eval 579 2.3694 canon_true_dependence 504 2.0624 check_dependence 479 1.9601 is_gimple_stmt 460 1.8824 ggc_alloc_stat 343 1.4036 for_each_rtx 327 1.3381 walk_tree 300 1.2276 base_alias_check 270 1.1049 poison_pages 258 1.0558 schedule_block 253 1.0353 cse_insn -- Summary: Long compile time for array initializer with inlined constructor Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org @ 2005-08-19 23:03 ` pinskia at gcc dot gnu dot org 2005-08-19 23:27 ` pinskia at gcc dot gnu dot org ` (6 subsequent siblings) 7 siblings, 0 replies; 14+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-08-19 23:03 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 23:01 ------- The only things in your profile which is tree based: 479 1.9601 is_gimple_stmt 327 1.3381 walk_tree The rest are rtl based. So this is a RTL issue. -- What |Removed |Added ---------------------------------------------------------------------------- Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org 2005-08-19 23:03 ` [Bug rtl-optimization/23490] " pinskia at gcc dot gnu dot org @ 2005-08-19 23:27 ` pinskia at gcc dot gnu dot org 2005-08-20 2:29 ` [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] " pinskia at gcc dot gnu dot org ` (5 subsequent siblings) 7 siblings, 0 replies; 14+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-08-19 23:27 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19 23:03 ------- (In reply to comment #1) > The only things in your profile which is tree based: > 479 1.9601 is_gimple_stmt > 327 1.3381 walk_tree Oh and those are most likely just checking and nothing more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org 2005-08-19 23:03 ` [Bug rtl-optimization/23490] " pinskia at gcc dot gnu dot org 2005-08-19 23:27 ` pinskia at gcc dot gnu dot org @ 2005-08-20 2:29 ` pinskia at gcc dot gnu dot org 2005-09-19 0:02 ` pinskia at gcc dot gnu dot org ` (4 subsequent siblings) 7 siblings, 0 replies; 14+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-08-20 2:29 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 02:26 ------- earth:~>time gcc -O1 t.cc -S 5.993u 0.056s 0:06.18 97.7% 0+0k 0+0io 0pf+0w earth:~>time gcc -O1 t.cc -S -O2 11.529u 0.058s 0:11.84 97.7% 0+0k 0+0io 0pf+0w earth:~>time gcc t.cc -S 0.426u 0.012s 0:00.93 46.2% 0+0k 0+0io 0pf+0w This is without checking disable. Interesting 2.95.3 does not have the issue even with -fstrict-aliasing: earth:~>time ~/ia32_linux_gcc2_95/bin/gcc t.cc -S 0.248u 0.019s 0:00.51 49.0% 0+0k 0+0io 0pf+0w earth:~>time ~/ia32_linux_gcc2_95/bin/gcc t.cc -S -O1 1.259u 0.013s 0:01.63 77.3% 0+0k 0+0io 0pf+0w earth:~>time ~/ia32_linux_gcc2_95/bin/gcc t.cc -S -O2 1.630u 0.021s 0:01.90 86.8% 0+0k 0+0io 0pf+0w earth:~>time ~/ia32_linux_gcc2_95/bin/gcc t.cc -S -O2 -fstrict-aliasing 1.626u 0.018s 0:01.81 90.0% 0+0k 0+0io 0pf+0w This has been a bug since 3.0.4. It also happens on x86 too. -- What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed| |1 GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | GCC target triplet|alphaev68-unknown-linux-gnu | Known to fail| |3.0.4 3.3.3 3.4.0 4.0.0 Known to work| |2.95.3 Last reconfirmed|0000-00-00 00:00:00 |2005-08-20 02:26:31 date| | Summary|Long compile time for array |[3.4/4.0/4.1 Regression] |initializer with inlined |Long compile time for array |constructor |initializer with inlined | |constructor Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org ` (2 preceding siblings ...) 2005-08-20 2:29 ` [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] " pinskia at gcc dot gnu dot org @ 2005-09-19 0:02 ` pinskia at gcc dot gnu dot org 2005-09-19 0:05 ` pinskia at gcc dot gnu dot org ` (3 subsequent siblings) 7 siblings, 0 replies; 14+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-09-19 0:02 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19 00:02 ------- On the mainline at -O3 on x86_64-pc-linux-gnu: CSE : 2.15 (13%) usr 0.01 ( 7%) sys 2.14 (12%) wall 257 kB ( 0%) ggc CSE 2 : 1.50 ( 9%) usr 0.00 ( 0%) sys 1.49 ( 9%) wall 0 kB ( 0%) ggc reload CSE regs : 2.19 (13%) usr 0.00 ( 0%) sys 2.20 (13%) wall 257 kB ( 0%) ggc load CSE after reload : 8.46 (50%) usr 0.00 ( 0%) sys 8.46 (49%) wall 0 kB ( 0%) ggc So this is definitely a RTL problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org ` (3 preceding siblings ...) 2005-09-19 0:02 ` pinskia at gcc dot gnu dot org @ 2005-09-19 0:05 ` pinskia at gcc dot gnu dot org 2005-09-19 0:07 ` steven at gcc dot gnu dot org ` (2 subsequent siblings) 7 siblings, 0 replies; 14+ messages in thread From: pinskia at gcc dot gnu dot org @ 2005-09-19 0:05 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19 00:05 ------- (In reply to comment #4) > load CSE after reload : 8.46 (50%) usr 0.00 ( 0%) sys 8.46 (49%) wall 0 kB ( 0%) ggc This is only thing which does not show up at -O2. The rest shows up with about the same compile time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org ` (4 preceding siblings ...) 2005-09-19 0:05 ` pinskia at gcc dot gnu dot org @ 2005-09-19 0:07 ` steven at gcc dot gnu dot org 2005-09-19 11:07 ` steven at gcc dot gnu dot org 2005-09-27 16:15 ` mmitchel at gcc dot gnu dot org 7 siblings, 0 replies; 14+ messages in thread From: steven at gcc dot gnu dot org @ 2005-09-19 0:07 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From steven at gcc dot gnu dot org 2005-09-19 00:07 ------- I'll look at the "load CSE after reload" (postreload-gcse, gddmmtgrmbl!), which I've looked at before. The top functions in the profile of the report are from RTL alias analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org ` (5 preceding siblings ...) 2005-09-19 0:07 ` steven at gcc dot gnu dot org @ 2005-09-19 11:07 ` steven at gcc dot gnu dot org 2005-09-27 16:15 ` mmitchel at gcc dot gnu dot org 7 siblings, 0 replies; 14+ messages in thread From: steven at gcc dot gnu dot org @ 2005-09-19 11:07 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From steven at gcc dot gnu dot org 2005-09-19 11:07 ------- Even the bad timings for postreload-gcse are almost entirely to blame on RTL alias analysis: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.18 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 1000000 samples % symbol name 4503 10.9264 rtx_equal_for_memref_p 3080 7.4736 canon_rtx 2298 5.5760 memrefs_conflict_p 2219 5.3844 find_base_term 2057 4.9913 ix86_find_base_term 1877 4.5545 nonoverlapping_component_refs_p 1474 3.5766 for_each_rtx_1 1412 3.4262 nonoverlapping_memrefs_p 1386 3.3631 addr_side_effect_eval 1279 3.1035 mems_in_disjoint_alias_sets_p 764 1.8538 get_addr 710 1.7228 exp_equiv_p 682 1.6549 invalidate 604 1.4656 check_dependence 587 1.4243 is_gimple_stmt 579 1.4049 cselib_invalidate_mem 553 1.3418 canon_true_dependence 532 1.2909 rtx_equal_p 406 0.9851 cse_insn 398 0.9657 decl_for_component_ref 359 0.8711 ldst_entry 341 0.8274 verify_expr 304 0.7376 walk_tree 272 0.6600 alias_sets_conflict_p 272 0.6600 base_alias_check -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org ` (6 preceding siblings ...) 2005-09-19 11:07 ` steven at gcc dot gnu dot org @ 2005-09-27 16:15 ` mmitchel at gcc dot gnu dot org 7 siblings, 0 replies; 14+ messages in thread From: mmitchel at gcc dot gnu dot org @ 2005-09-27 16:15 UTC (permalink / raw) To: gcc-bugs -- What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <bug-23490-2744@http.gcc.gnu.org/bugzilla/>]
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> @ 2005-10-31 5:17 ` mmitchel at gcc dot gnu dot org 2005-11-03 20:06 ` hubicka at gcc dot gnu dot org ` (3 subsequent siblings) 4 siblings, 0 replies; 14+ messages in thread From: mmitchel at gcc dot gnu dot org @ 2005-10-31 5:17 UTC (permalink / raw) To: gcc-bugs ------- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:17 ------- I'd like to see this fixed. Is there any throttling we can do here? -- mmitchel at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> 2005-10-31 5:17 ` mmitchel at gcc dot gnu dot org @ 2005-11-03 20:06 ` hubicka at gcc dot gnu dot org 2005-11-03 20:20 ` falk at debian dot org ` (2 subsequent siblings) 4 siblings, 0 replies; 14+ messages in thread From: hubicka at gcc dot gnu dot org @ 2005-11-03 20:06 UTC (permalink / raw) To: gcc-bugs ------- Comment #9 from hubicka at gcc dot gnu dot org 2005-11-03 20:06 ------- For reload CSE there is --param max-cselib-memory-locations=10 that cuts it's time to 1%, overall. Since this testcase is sort of designed to excercise the worst case behaviour, I think it is not too bad... alias analysis has: /* Maximum length of pbi->mem_set_list before we start dropping new elements on the floor. */ #define MAX_MEM_SET_LIST_LEN 100 perhaps unifying all these lists would make sense. Would that be applicable for 4.1? (Ie I would have to pick some common value, like 300 - cselib defaults to 500) CSE has: /* If we have processed 1,000 insns, flush the hash table to avoid extreme quadratic behavior. We must not include NOTEs in the count since there may be more of them when generating debugging information. If we clear the table at different times, code generated with -g -O might be different than code generated with -O but not -g. ??? This is a real kludge and needs to be done some other way. Perhaps for 2.9. */ I am not sure if I can fit memory specific limit in this (it would be nice to simply throw away old entries rather than flushing it all), or we can just keep it. None of these algorithms would grow ad infimum and manifest worse behaviour than in this testcase, so I would not consider it P2 Honza -- hubicka at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> 2005-10-31 5:17 ` mmitchel at gcc dot gnu dot org 2005-11-03 20:06 ` hubicka at gcc dot gnu dot org @ 2005-11-03 20:20 ` falk at debian dot org 2005-11-03 21:23 ` hubicka at ucw dot cz 2005-11-05 0:55 ` hubicka at gcc dot gnu dot org 4 siblings, 0 replies; 14+ messages in thread From: falk at debian dot org @ 2005-11-03 20:20 UTC (permalink / raw) To: gcc-bugs ------- Comment #10 from falk at debian dot org 2005-11-03 20:20 ------- Created an attachment (id=10134) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10134&action=view) Preprocessed test case This is not a designed test case, it's distilled from a real-world application (libqd). I've attached the original source. g++ -O2 takes 103s for 33667 lines (about 1M, not really very large for preprocessed C++). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2005-11-03 20:20 ` falk at debian dot org @ 2005-11-03 21:23 ` hubicka at ucw dot cz 2005-11-05 0:55 ` hubicka at gcc dot gnu dot org 4 siblings, 0 replies; 14+ messages in thread From: hubicka at ucw dot cz @ 2005-11-03 21:23 UTC (permalink / raw) To: gcc-bugs ------- Comment #11 from hubicka at ucw dot cz 2005-11-03 21:23 ------- Subject: Re: [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor Hmm, OK, this adds the neccesary knobs so you can trottle the parameters even further. Sadly this brings quite dificult to tune parameters since reducing them considerably might easilly ruin code quality and I am unsure how we want to proceed... (IE keep them high and change your makefiles or try to reduce them to something more scalable) Honza 2005-11-03 Jan Hubicka <jh@suse.cz> * doc/invoke.texi (max-predicted-iterations, max-cse-insns, max-flow-memory-location): Document. * flow.c: Include params.h (MAX_MEM_SET_LIST_LEN): Kill. (add_to_mem_set_list): Use new param. * cse.c (cse_basic_block): Replace 1000 by new param. * params.def (PARAM_MAX_PREDICTED_ITERATIONS, PARAM_MAX_CSE_INSNS, PARAM_MAX_FLOW_MEMORY_LOCATIONS): New. * predict.c (predict_loops): Use new param. * predict.def (MAX_PRED_LOOP_ITERATIONS): Remove. Index: doc/invoke.texi =================================================================== --- doc/invoke.texi (revision 106422) +++ doc/invoke.texi (working copy) @@ -5934,6 +5938,13 @@ given basic block needs to have to be co Select fraction of the maximal frequency of executions of basic block in function given basic block needs to have to be considered hot +@item max-predicted-iterations +The maximum number of loop iterations we predict statically. This is useful +in cases where function contain single loop with known bound and other loop +with unknown. We predict the known number of iterations correctly, while +the unknown nummber of iterations average to roughly 10. This means that the +loop without bounds would appear artifically cold relative to the other one. + @item tracer-dynamic-coverage @itemx tracer-dynamic-coverage-feedback @@ -5971,6 +5982,9 @@ order to make tracer effective. Maximum number of basic blocks on path that cse considers. The default is 10. +@item max-cse-insns +The maximum instructions CSE process before flushing. The default is 1000. + @item global-var-threshold Counts the number of function calls (@var{n}) and the number of @@ -6031,6 +6045,10 @@ value is 100. The maximum number of memory locations cselib should take into acount. Increasing values mean more aggressive optimization, making the compile time increase with probably slightly better performance. The default value is 500. + +@item max-flow-memory-location +Similar as @option{max-cselib-memory-location} but for dataflow liveness. +The default value is 100. @item reorder-blocks-duplicate @itemx reorder-blocks-duplicate-feedback Index: flow.c =================================================================== --- flow.c (revision 106422) +++ flow.c (working copy) @@ -141,6 +141,7 @@ Software Foundation, 51 Franklin Street, #include "obstack.h" #include "splay-tree.h" #include "tree-pass.h" +#include "params.h" #ifndef HAVE_epilogue #define HAVE_epilogue 0 @@ -283,10 +284,6 @@ static int ndead; static int *reg_deaths; -/* Maximum length of pbi->mem_set_list before we start dropping - new elements on the floor. */ -#define MAX_MEM_SET_LIST_LEN 100 - /* Forward declarations */ static int verify_wide_reg_1 (rtx *, void *); static void verify_wide_reg (int, basic_block); @@ -630,7 +627,7 @@ update_life_info (sbitmap blocks, enum u /* We repeat regardless of what cleanup_cfg says. If there were instructions deleted above, that might have been only a - partial improvement (see MAX_MEM_SET_LIST_LEN usage). + partial improvement (see PARAM_MAX_FLOW_MEMORY_LOCATIONS usage). Further improvement may be possible. */ cleanup_cfg (CLEANUP_EXPENSIVE); @@ -2515,7 +2512,7 @@ add_to_mem_set_list (struct propagate_bl } } - if (pbi->mem_set_list_len < MAX_MEM_SET_LIST_LEN) + if (pbi->mem_set_list_len < PARAM_VALUE (PARAM_MAX_FLOW_MEMORY_LOCATIONS)) { #ifdef AUTO_INC_DEC /* Store a copy of mem, otherwise the address may be Index: cse.c =================================================================== --- cse.c (revision 106422) +++ cse.c (working copy) @@ -6890,7 +6890,7 @@ cse_basic_block (rtx from, rtx to, struc ??? This is a real kludge and needs to be done some other way. Perhaps for 2.9. */ - if (code != NOTE && num_insns++ > 1000) + if (code != NOTE && num_insns++ > PARAM_VALUE (PARAM_MAX_CSE_INSNS)) { flush_hash_table (); num_insns = 0; Index: predict.c =================================================================== --- predict.c (revision 106422) +++ predict.c (working copy) @@ -624,8 +624,9 @@ predict_loops (struct loops *loops_info, niter = desc.niter + 1; if (niter == 0) /* We might overflow here. */ niter = desc.niter; - if (niter > MAX_PRED_LOOP_ITERATIONS) - niter = MAX_PRED_LOOP_ITERATIONS; + if (niter + > (unsigned int) PARAM_VALUE (PARAM_MAX_PREDICTED_ITERATIONS)) + niter = PARAM_VALUE (PARAM_MAX_PREDICTED_ITERATIONS); prob = (REG_BR_PROB_BASE - (REG_BR_PROB_BASE + niter /2) / niter); @@ -653,19 +654,17 @@ predict_loops (struct loops *loops_info, if (TREE_CODE (niter) == INTEGER_CST) { int probability; + int max = PARAM_VALUE (PARAM_MAX_PREDICTED_ITERATIONS); if (host_integerp (niter, 1) && tree_int_cst_lt (niter, - build_int_cstu (NULL_TREE, - MAX_PRED_LOOP_ITERATIONS - 1))) + build_int_cstu (NULL_TREE, max - 1))) { HOST_WIDE_INT nitercst = tree_low_cst (niter, 1) + 1; probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst); } else - probability = ((REG_BR_PROB_BASE - + MAX_PRED_LOOP_ITERATIONS / 2) - / MAX_PRED_LOOP_ITERATIONS); + probability = ((REG_BR_PROB_BASE + max / 2) / max); predict_edge (exits[j], PRED_LOOP_ITERATIONS, probability); } Index: params.def =================================================================== --- params.def (revision 106422) +++ params.def (working copy) @@ -309,6 +309,22 @@ DEFPARAM(HOT_BB_FREQUENCY_FRACTION, "hot-bb-frequency-fraction", "Select fraction of the maximal frequency of executions of basic block in function given basic block needs to have to be considered hot", 1000, 0, 0) + +/* For guessed profiles, the loops having unknown number of iterations + are predicted to iterate relatively few (10) times at average. + For functions containing one loop with large known number of iterations + and other loops having unbounded loops we would end up predicting all + the other loops cold that is not usually the case. So we need to artifically + flatten the profile. + + We need to cut the maximal predicted iterations to large enought iterations + so the loop appears important, but safely within HOT_BB_COUNT_FRACTION + range. */ + +DEFPARAM(PARAM_MAX_PREDICTED_ITERATIONS, + "max-predicted-iterations", + "The maximum number of loop iterations we predict statically", + 100, 0, 0) DEFPARAM(TRACER_DYNAMIC_COVERAGE_FEEDBACK, "tracer-dynamic-coverage-feedback", "The percentage of function, weighted by execution frequency, that must be covered by trace formation. Used when profile feedback is available", @@ -363,6 +379,10 @@ DEFPARAM(PARAM_MAX_CSE_PATH_LENGTH, "max-cse-path-length", "The maximum length of path considered in cse", 10, 0, 0) +DEFPARAM(PARAM_MAX_CSE_INSNS, + "max-flow-memory-locations", + "The maximum instructions CSE process before flushing", + 1000, 0, 0) /* The cost of expression in loop invariant motion that is considered expensive. */ @@ -417,6 +437,10 @@ DEFPARAM(PARAM_MAX_CSELIB_MEMORY_LOCATIO "max-cselib-memory-locations", "The maximum memory locations recorded by cselib", 500, 0, 0) +DEFPARAM(PARAM_MAX_FLOW_MEMORY_LOCATIONS, + "max-flow-memory-locations", + "The maximum memory locations recorded by flow", + 100, 0, 0) #ifdef ENABLE_GC_ALWAYS_COLLECT # define GGC_MIN_EXPAND_DEFAULT 0 Index: predict.def =================================================================== --- predict.def (revision 106422) +++ predict.def (working copy) @@ -58,18 +58,6 @@ DEF_PREDICTOR (PRED_UNCONDITIONAL, "unco DEF_PREDICTOR (PRED_LOOP_ITERATIONS, "loop iterations", PROB_ALWAYS, PRED_FLAG_FIRST_MATCH) -/* For guessed profiles, the loops having unknown number of iterations - are predicted to iterate relatively few (10) times at average. - For functions containing one loop with large known number of iterations - and other loops having unbounded loops we would end up predicting all - the other loops cold that is not usually the case. So we need to artifically - flatten the profile. - - We need to cut the maximal predicted iterations to large enought iterations - so the loop appears important, but safely within HOT_BB_COUNT_FRACTION - range. */ -#define MAX_PRED_LOOP_ITERATIONS 100 - /* Hints dropped by user via __builtin_expect feature. */ DEF_PREDICTOR (PRED_BUILTIN_EXPECT, "__builtin_expect", PROB_VERY_LIKELY, PRED_FLAG_FIRST_MATCH) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] Long compile time for array initializer with inlined constructor [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> ` (3 preceding siblings ...) 2005-11-03 21:23 ` hubicka at ucw dot cz @ 2005-11-05 0:55 ` hubicka at gcc dot gnu dot org 4 siblings, 0 replies; 14+ messages in thread From: hubicka at gcc dot gnu dot org @ 2005-11-05 0:55 UTC (permalink / raw) To: gcc-bugs ------- Comment #12 from hubicka at gcc dot gnu dot org 2005-11-05 00:55 ------- Subject: Bug 23490 Author: hubicka Date: Sat Nov 5 00:55:23 2005 New Revision: 106520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106520 Log: PR rtl-optimization/23490 * doc/invoke.texi (max-predicted-iterations, max-cse-insns, max-flow-memory-location): Document. * flow.c: Include params.h (MAX_MEM_SET_LIST_LEN): Kill. (add_to_mem_set_list): Use new param. * cse.c (cse_basic_block): Replace 1000 by new param. * params.def (PARAM_MAX_PREDICTED_ITERATIONS, PARAM_MAX_CSE_INSNS, PARAM_MAX_FLOW_MEMORY_LOCATIONS): New. * predict.c (predict_loops): Use new param. * predict.def (MAX_PRED_LOOP_ITERATIONS): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/doc/invoke.texi trunk/gcc/flow.c trunk/gcc/params.def trunk/gcc/predict.c trunk/gcc/predict.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2005-11-05 0:55 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-19 22:48 [Bug tree-optimization/23490] New: Long compile time for array initializer with inlined constructor falk at debian dot org 2005-08-19 23:03 ` [Bug rtl-optimization/23490] " pinskia at gcc dot gnu dot org 2005-08-19 23:27 ` pinskia at gcc dot gnu dot org 2005-08-20 2:29 ` [Bug rtl-optimization/23490] [3.4/4.0/4.1 Regression] " pinskia at gcc dot gnu dot org 2005-09-19 0:02 ` pinskia at gcc dot gnu dot org 2005-09-19 0:05 ` pinskia at gcc dot gnu dot org 2005-09-19 0:07 ` steven at gcc dot gnu dot org 2005-09-19 11:07 ` steven at gcc dot gnu dot org 2005-09-27 16:15 ` mmitchel at gcc dot gnu dot org [not found] <bug-23490-2744@http.gcc.gnu.org/bugzilla/> 2005-10-31 5:17 ` mmitchel at gcc dot gnu dot org 2005-11-03 20:06 ` hubicka at gcc dot gnu dot org 2005-11-03 20:20 ` falk at debian dot org 2005-11-03 21:23 ` hubicka at ucw dot cz 2005-11-05 0:55 ` hubicka at gcc dot gnu dot org
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).