public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options
@ 2014-09-26 17:33 andi-gcc at firstfloor dot org
  2014-09-28  1:22 ` [Bug rtl-optimization/63384] " andi-gcc at firstfloor dot org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-26 17:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

            Bug ID: 63384
           Summary: ICE in moveup_expr_chached->sel_bb_head->bb_node with
                    special options
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andi-gcc at firstfloor dot org

Created attachment 33585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33585&action=edit
test case (non minimized)

The following combination of options causes an ICE with the attached test case:

g++50 matrix.i -o outfile -O2  -fsel-sched-pipelining-outer-loops
-fsel-sched-reschedule-pipelined -fvar-tracking-assignments-toggle
-ftree-vectorize -fselective-scheduling2

gcc version 4.9.0 20130617 (experimental) (GCC) 

apps/matrixmultiply.cpp: In function 'T** make_test_matrix() [with T = float]':
apps/matrixmultiply.cpp:22:1: internal compiler error: Segmentation fault
 }
 ^
0x8cde37 crash_signal
        ../../gcc/gcc/toplev.c:333
0x6764e1 bb_note(basic_block_def*)
        ../../gcc/gcc/cfgrtl.c:647
0x89c1a1 sel_bb_head(basic_block_def*)
        ../../gcc/gcc/sel-sched-ir.c:4536
0x8a6fa5 moveup_expr_cached
        ../../gcc/gcc/sel-sched.c:2563
0x8ac506 move_op_ascend
        ../../gcc/gcc/sel-sched.c:6217
0x8aabc7 code_motion_path_driver
        ../../gcc/gcc/sel-sched.c:6706
0x8aca54 move_op
        ../../gcc/gcc/sel-sched.c:6758
0x8aca54 move_exprs_to_boundary
        ../../gcc/gcc/sel-sched.c:5292
0x8aca54 schedule_expr_on_boundary
        ../../gcc/gcc/sel-sched.c:5504
0x8af552 fill_insns
        ../../gcc/gcc/sel-sched.c:5646
0x8af552 schedule_on_fences
        ../../gcc/gcc/sel-sched.c:7410
0x8af552 sel_sched_region_2
        ../../gcc/gcc/sel-sched.c:7544
0x8b14bf sel_sched_region_1
        ../../gcc/gcc/sel-sched.c:7583
0x8b14bf sel_sched_region(int)
        ../../gcc/gcc/sel-sched.c:7684
0x8b1fc1 run_selective_scheduling()
        ../../gcc/gcc/sel-sched.c:7760
0x895b56 rest_of_handle_sched2
        ../../gcc/gcc/sched-rgn.c:3606


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/63384] ICE in moveup_expr_chached->sel_bb_head->bb_node with special options
  2014-09-26 17:33 [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options andi-gcc at firstfloor dot org
@ 2014-09-28  1:22 ` andi-gcc at firstfloor dot org
  2014-09-28  7:43 ` [Bug rtl-optimization/63384] selective scheduling on x86 takes very long andi-gcc at firstfloor dot org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28  1:22 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5288 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #1 from Andi Kleen <andi-gcc at firstfloor dot org> ---
With a newer compiler version

gcc version 5.0.0 20140926 (experimental) (GCC) 


the test case doesn't crash anymore, but just runs very very long. I killed it
after 20s. This happens with the following two options:


g++50 matrix.i -o outfile -O2  -fvar-tracking-assignments-toggle 
-fselective-scheduling2

The overhead is mostly in the scheduler:

  - sched_analyze_insn(deps_desc*, rtx_def*, rtx_insn*)                     â–’
      - 99.39% deps_analyze_insn(deps_desc*, rtx_insn*)                      â–’
           tick_check_p(_expr*, deps_desc*, _fence*)                         â–’
           fill_insns(_fence*, int, _list_node***)                           â–’
           sel_sched_region_2(int)                                           â–’
           sel_sched_region(int)                                             â–’
           run_selective_scheduling()                                        â–’
           (anonymous namespace)::pass_sched2::execute(function*)            â–’
           execute_one_pass(opt_pass*)                                       â–’
           execute_pass_list_1(opt_pass*)                                    â–’
           execute_pass_list_1(opt_pass*)                                    â–’
           execute_pass_list_1(opt_pass*)                                    â–’
           execute_pass_list(function*, opt_pass*)                           â–’
           cgraph_node::expand()                                             â–’
           symbol_table::compile()                                           â–’
           symbol_table::finalize_compilation_unit()                         â–’
           cp_write_global_declarations()                                    â–’
           compile_file()                                                    â–’
           toplev_main(int, char**)                                          â–’
           __libc_start_main                                                 â–’
      + 0.61% tick_check_p(_expr*, deps_desc*, _fence*)         


sched_analyze_insn(deps_desc*, rtx_def*, rtx_insn*)                             


       │
       │            for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
 12.84 │ 748:   add    $0x1,%r13d
  0.07 │        add    $0x30,%r14
       │        cmp    $0x4d,%r13d
       │      ↓ je     7e5
       │              if (TEST_HARD_REG_BIT (implicit_reg_pending_uses, i))
  0.06 │ 75a:   mov    %r13d,%eax
 12.45 │        shr    $0x6,%eax
  0.17 │        mov    0x1828100(,%rax,8),%rax
  6.06 │        bt     %r13,%rax
  6.21 │      ↑ jae    748
       │                {
>From gcc-bugs-return-462745-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Sep 28 02:02:25 2014
Return-Path: <gcc-bugs-return-462745-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2719 invoked by alias); 28 Sep 2014 02:02:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32634 invoked by uid 48); 28 Sep 2014 02:02:09 -0000
From: "andi-gcc at firstfloor dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63384] selective scheduling on x86 takes very long
Date: Sun, 28 Sep 2014 02:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: andi-gcc at firstfloor dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-63384-4-UN5MJ4jfWB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63384-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63384-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02579.txt.bz2
Content-length: 638

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc384

Andi Kleen <andi-gcc at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33585|0                           |1
        is obsolete|                            |

--- Comment #2 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Created attachment 33600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3600&actioníit
Reduced test case for long compile time

Oddly the problem goes away when the variable allocation that is not used is
commented out.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/63384] selective scheduling on x86 takes very long
  2014-09-26 17:33 [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options andi-gcc at firstfloor dot org
  2014-09-28  1:22 ` [Bug rtl-optimization/63384] " andi-gcc at firstfloor dot org
@ 2014-09-28  7:43 ` andi-gcc at firstfloor dot org
  2014-09-28 17:27 ` [Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86 andi-gcc at firstfloor dot org
  2024-06-21 23:15 ` andi-gcc at firstfloor dot org
  3 siblings, 0 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28  7:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #3 from Andi Kleen <andi-gcc at firstfloor dot org> ---
It loops (forever?) on this in sched2:


Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed

Scheduling on fences: (uid:28;seqno:7;) 
Fence 28[2] has not changed


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86
  2014-09-26 17:33 [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options andi-gcc at firstfloor dot org
  2014-09-28  1:22 ` [Bug rtl-optimization/63384] " andi-gcc at firstfloor dot org
  2014-09-28  7:43 ` [Bug rtl-optimization/63384] selective scheduling on x86 takes very long andi-gcc at firstfloor dot org
@ 2014-09-28 17:27 ` andi-gcc at firstfloor dot org
  2024-06-21 23:15 ` andi-gcc at firstfloor dot org
  3 siblings, 0 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2014-09-28 17:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #4 from Andi Kleen <andi-gcc at firstfloor dot org> ---
It loops forever in this loop in sel_sched_region_2

  while (fences)
    {
      int min_seqno, max_seqno;
      ilist_t scheduled_insns = NULL;
      ilist_t *scheduled_insns_tailp = &scheduled_insns;

      find_min_max_seqno (fences, &min_seqno, &max_seqno);
      schedule_on_fences (fences, max_seqno, &scheduled_insns_tailp);
      fences = calculate_new_fences (fences, orig_max_seqno, &max_time);
      highest_seqno_in_use = update_seqnos_and_stage (min_seqno, max_seqno,
                                                      highest_seqno_in_use,
                                                      &scheduled_insns);
    }

because calculate_new_fences always comes up with a list which is the same as
before. In move_fence_to_fences it always goes into the else

 f = flist_lookup (FLIST_TAIL_HEAD (new_fences),
                    FENCE_INSN (FLIST_FENCE (old_fences)));
  if (f)
    {
      merge_fences (f, old->insn, old->state, old->dc, old->tc,
                    old->last_scheduled_insn, old->executing_insns,
                    old->ready_ticks, old->ready_ticks_size,
                    old->sched_next, old->cycle, old->issue_more,
                    old->after_stall_p);
    }
  else
    {
      _list_add (tailp);
      FLIST_TAIL_TAILP (new_fences) = &FLIST_NEXT (*tailp);


So something is going wrong in flist_lookup.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86
  2014-09-26 17:33 [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options andi-gcc at firstfloor dot org
                   ` (2 preceding siblings ...)
  2014-09-28 17:27 ` [Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86 andi-gcc at firstfloor dot org
@ 2024-06-21 23:15 ` andi-gcc at firstfloor dot org
  3 siblings, 0 replies; 5+ messages in thread
From: andi-gcc at firstfloor dot org @ 2024-06-21 23:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

Andi Kleen <andi-gcc at firstfloor dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #9 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Long fixed.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-06-21 23:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-26 17:33 [Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options andi-gcc at firstfloor dot org
2014-09-28  1:22 ` [Bug rtl-optimization/63384] " andi-gcc at firstfloor dot org
2014-09-28  7:43 ` [Bug rtl-optimization/63384] selective scheduling on x86 takes very long andi-gcc at firstfloor dot org
2014-09-28 17:27 ` [Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86 andi-gcc at firstfloor dot org
2024-06-21 23:15 ` andi-gcc at firstfloor 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).