https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519
--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #1)
> We diverge in sched1 due to extra calls to advance_one_cycle when scheduling
> a BB that is empty apart from one debug insn. The following patch adds a
> hexdump of automaton state to make the problem evident:
>
> diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
> index 420c45dff..c09398897 100644
> --- a/gcc/sched-rgn.cc
> +++ b/gcc/sched-rgn.cc
> @@ -3098,8 +3098,14 @@ save_state_for_fallthru_edge (basic_block last_bb,
> state_t state)
> memcpy (bb_state[f->dest->index], state,
> dfa_state_size);
> if (sched_verbose >= 5)
> - fprintf (sched_dump, "saving state for edge %d->%d\n",
> - f->src->index, f->dest->index);
> + {
> + fprintf (sched_dump, "saving state for edge %d->%d\n",
> + f->src->index, f->dest->index);
> + for (size_t i = 0; i < dfa_state_size; i++)
> + fprintf (sched_dump, "%02x%c", i[(unsigned char *)state],
> + (i+1) % 16 ? ' ' : '\n');
> + fprintf(sched_dump, "\n---\n");
> + }
> }
> }
>
> With the above patch it's obvious we advance the automaton state a few extra
> times when scheduling BB 3, and then inherit the modified state to BB 4.
Nice tips for dumping!
>
> I think we don't need to schedule blocks that only contain debug insns. IBM
> folks, care to test the following?
Yes, I agree. I attached one patch in PR108273 which also proposed to consider
DEBUG_INSN_P in no_real_insns_p, it's bootstrapped and regress-tested on
powerpc64 and powerpc64le, I'm going to test it on x86 and aarch64 if it's on
the right track. As to your proposed change in free_block_dependencies, I also
tried that before (it can make this test case compilation happy, yes :)), but
unfortunately it gets abort at
383│ free_deps_list (deps_list_t l)
384│ {
385├─> gcc_assert (deps_list_empty_p (l));
for some cases in building libgcc, the root cause is that some block can have
more than one debug insn, there are some deps between them, I think the current
free_block_dependencies has the assumption that the deps which need to be
resolved would be handled during scheduling insn, so it calls sched_free_deps
with resolved_p "true", then it still leaves the deps like INSN_FORW_DEPS
uncleared, which is unexpected and caused the ICE.
