[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-02-23 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

--- Comment #5 from Kewen Lin  ---
(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.

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-02-23 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||linkw at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Kewen Lin  ---
This one is dup of PR108273, the culprit commit just exposes this latent issue
on Power8 LE (and also cover the failure on Power10 LE).

*** This bug has been marked as a duplicate of bug 108273 ***

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-01-26 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

--- Comment #3 from Alexander Monakov  ---
Ah, a worthy sequel to "Note that I wasn't able to figure out a usable email
address for the submitter" from PR 107353. Nevermind then.

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-01-26 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

--- Comment #2 from seurer at gcc dot gnu.org ---
I tried to test that patch but it didn't apply cleanly.

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-01-25 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

--- Comment #1 from Alexander Monakov  ---
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.

I think we don't need to schedule blocks that only contain debug insns. IBM
folks, care to test the following?

diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 4efaa9445..f00a92e26 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -5040,7 +5040,7 @@ no_real_insns_p (const rtx_insn *head, const rtx_insn
*tail)
 {
   while (head != NEXT_INSN (tail))
 {
-  if (!NOTE_P (head) && !LABEL_P (head))
+  if (!NOTE_P (head) && !LABEL_P (head) && !DEBUG_INSN_P (head))
return 0;
   head = NEXT_INSN (head);
 }
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
@@ -2753,7 +2753,7 @@ free_block_dependencies (int bb)

   get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), , );

-  if (no_real_insns_p (head, tail))
+  if (0 && no_real_insns_p (head, tail))
 return;

   sched_free_deps (head, tail, true);

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

2023-01-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519

Richard Biener  changed:

   What|Removed |Added

   Keywords||compare-debug-failure,
   ||testsuite-fail
  Component|other   |rtl-optimization
   Target Milestone|--- |13.0
   Priority|P3  |P1