[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

2018-04-09 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913

--- Comment #4 from Andrey Belevantsev  ---
Author: abel
Date: Mon Apr  9 09:42:25 2018
New Revision: 259230

URL: https://gcc.gnu.org/viewcvs?rev=259230=gcc=rev
Log:
   PR rtl-optimization/83913

   * sel-sched-ir.c (merge_expr_data): Choose the middle between two
   different sched-times when merging exprs.

   * gcc.dg/pr83913.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr83913.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

2018-01-23 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913

Andrey Belevantsev  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |abel at gcc dot gnu.org

--- Comment #3 from Andrey Belevantsev  ---
We've discussed with Alexander about this one.  The simpler fix will be never
pipelining anything of priority 0, as this wouldn't give any benefit.  The
better fix is to make bookkeeping copies within the pipelined region inherit
sched_times -- the number of times this insn was scheduled.  It will not work
for regular scheduling as those new insns have to be scheduled at some point,
but for pipelined regions we're rescheduling blocks with new insns anyways.  So
something like below works, but for that kind of patch I will need testing on
ia64 and it takes time.

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 76092f9587a..58f4ca4016f 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -4773,7 +4773,16 @@ emit_bookkeeping_insn (insn_t place_to_insert, expr_t
c_expr, int new_seqno)
   insn_t new_insn = emit_insn_from_expr_after (c_expr, new_vinsn, new_seqno,
   place_to_insert);

-  INSN_SCHED_TIMES (new_insn) = 0;
+  if (pipelining_p && !sel_is_loop_preheader_p (BLOCK_FOR_INSN
(place_to_insert)))
+{
+  int sched_times = EXPR_SCHED_TIMES (c_expr);
+  if (sched_times < 0)
+   sched_times = 0;
+  INSN_SCHED_TIMES (new_insn) = sched_times;
+}
+  else
+INSN_SCHED_TIMES (new_insn) = 0;
+
   bitmap_set_bit (current_copies, INSN_UID (new_insn));

   return new_insn;

[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

2018-01-17 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913

--- Comment #2 from Alexander Monakov  ---
Thanks. While I could not find why we blow up with Haswell tuning but not say
Sandybridge, the main problem is that with all those -fno-... flags we have a
few insns of the form rK = rN where rN is loop-invariant and rK is unused, so
the insns are movable anywhere, including across the loop backedge (since
pipelining is enabled). We try to fill schedule holes (caused by long-latency
integer division insns) by repeatedly pipelining them. Eventually sched_times
cut off should prevent that, but it doesn't grow as intended because
bookkeeping copies get sched_times 0, and expr merging takes the minimum of two
sched_times.

[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

2018-01-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/83913] [6/7/8 Regression] Compile time and memory hog w/ selective scheduling

2018-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83913

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-17
 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|[8 Regression] Compile time |[6/7/8 Regression] Compile
   |and memory hog w/ selective |time and memory hog w/
   |scheduling  |selective scheduling
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r255395.
With additional -mtune=haswell it started in r227740 when the Haswell pipeline
description had been added.