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?

Reply via email to