public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd Date: Thu, 23 Feb 2023 09:46:39 +0000 [thread overview] Message-ID: <bug-108519-4-tWgnjO64qV@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108519-4@http.gcc.gnu.org/bugzilla/> 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.
prev parent reply other threads:[~2023-02-23 9:46 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-24 15:16 [Bug other/108519] New: " seurer at gcc dot gnu.org 2023-01-24 15:18 ` [Bug rtl-optimization/108519] " rguenth at gcc dot gnu.org 2023-01-25 16:12 ` amonakov at gcc dot gnu.org 2023-01-26 19:21 ` seurer at gcc dot gnu.org 2023-01-26 20:28 ` amonakov at gcc dot gnu.org 2023-02-23 9:12 ` linkw at gcc dot gnu.org 2023-02-23 9:46 ` linkw at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108519-4-tWgnjO64qV@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).