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).