[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
abel at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Jan 22 15:01:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
--- Comment #13 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
(In reply to Andrey Belevantsev from comment #12)
> (In reply to Arseny Solokha from comment #11)
> > How about this one? It makes only trunk gcc ICE, though.
> >
> > short int t2;
> > int cd, aa, ft;
> >
> > void
> > dh (void)
> > {
> > int qs = 0;
> >
> > if (t2 < 1)
> > {
> > int bq = 0;
> >
> > while (bq < 1)
> > {
> > }
> >
> > while (t2 < 1)
> > {
> > if (t2 == 0)
> > {
> > bq = 0;
> > cd = !!cd;
> > }
> > else
> > {
> > bq = 1;
> > cd = bq > qs;
> > }
> >
> > t2 += cd;
> > bq = (t2 / qs) == bq;
> >
> > if (aa != ft)
> > {
> > qs %= 0;
> > while (bq != 0)
> > {
> > ro:
> > ;
> > }
> > }
> >
> > ++t2;
> > }
> >
> > ia:
> > goto ro;
> > }
> >
> > goto ia;
> > }
> >
> > % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments
> > -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions
> > -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im
> > -fno-reorder-blocks-and-partition -fno-reorder-blocks
> > -fno-move-loop-invariants -w -c rsd2aiem.c
> > during RTL pass: sched2
> > rsd2aiem.c: In function 'dh':
> > rsd2aiem.c:51:1: internal compiler error: in
> > av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622
> > }
> > ^
> > 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3622
> > 0x64ad85 code_motion_process_successors
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6395
> > 0x64ad85 code_motion_path_driver
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc59886 code_motion_process_successors
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6351
> > 0xc59886 code_motion_path_driver
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc59886 code_motion_process_successors
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6351
> > 0xc59886 code_motion_path_driver
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc5aa5a find_used_regs
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3283
> > 0xc5aa5a collect_unavailable_regs_from_bnds
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:1598
> > 0xc5aa5a find_best_reg_for_expr
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:1661
> > 0xc5aa5a fill_vec_av_set
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3797
> > 0xc5da87 fill_ready_list
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:4027
> > 0xc5da87 find_best_expr
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:4387
> > 0xc5da87 fill_insns
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:5544
> > 0xc5da87 schedule_on_fences
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7361
> > 0xc5da87 sel_sched_region_2
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7499
> > 0xc61737 sel_sched_region_1
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7541
> > 0xc61737 sel_sched_region(int)
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7642
> > 0xc627a8 run_selective_scheduling()
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7718
> > 0xc42625 rest_of_handle_sched2
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sched-rgn.c:3729
> >
> > (as of r256677)
>
> Give me a few more days for unrelated stuff and I'll have enough time to
> look at this. If that turns to be the same dependence issue, we can check
> in a patch without waiting for hot/cold bbs issue to be sorted out.
So this one is unrelated to the original testcase. What happens is we have a
usual if then else control flow like this: bb 4 --> bb 5, bb 6; bb 5 --> bb 7;
bb 6 --> bb 7. There is a debug stmt in bb 6 sayng bq is 1. We end up moving
all stuff from bb 6 upwards. Without debug insns, bb 6 is about to be empty,
cfg simplifications in tidy_control_flow detect this and remove a jump from bb
5 to bb 7. However, when we do have them, there is a code that tries to mimic
the nondebug behavior and still removes the jump, but the block 6 itself is not
removed (it still has a debug insn). So now we have bb 5 --> bb 6 edge and the
scheduler crashes because the insns that were available at bb 6 suddenly become
unavailable (basically they have DFS numbers that are less than those of bb 5
and we do not go in that direction).
I can fix this by restoring the proper DFS numbers (seqnos) for this case,
something along the lines of:
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index a965d2ec42f..7b54f7f92d4 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3890,6 +3890,17 @@ tidy_control_flow (basic_block xbb, bool full_tidying)
gcc_assert (EDGE_SUCC (xbb->prev_bb, 0)->flags & EDGE_FALLTHRU);
+ if (MAY_HAVE_DEBUG_INSNS && (sel_bb_head (xbb) != first || sel_bb_end
(xbb) != last))
+ {
+ if (!sel_bb_empty_p (xbb->prev_bb))
+ {
+ int prev_seqno = INSN_SEQNO (sel_bb_end (xbb->prev_bb));
+ if (prev_seqno > INSN_SEQNO (sel_bb_head (xbb)))
+ for (insn_t insn = sel_bb_head (xbb); insn != first; insn =
NEXT_INSN (insn))
+ INSN_SEQNO (insn) = prev_seqno + 1;
+ }
+ }
+
/* It can turn out that after removing unused jump, basic block
that contained that jump, becomes empty too. In such case
remove it too. */
However the remaining debug insn is completely bogus at this point. Should I
reset it and if so, how? The Haifa scheduler does INSN_VAR_LOCATION_LOC (dbg)
= gen_rtx_UNKNOWN_VAR_LOC (); and the frees the reg use list. Or should I
remove the whole bb as it would be in the non-debug insn case?
More information about the Gcc-bugs
mailing list