public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	 Segher Boessenkool <segher@kernel.crashing.org>,
	 Peter Bergner <bergner@linux.ibm.com>,
	 Richard Biener <richard.guenther@gmail.com>,
	 Jeff Law <jeffreyalaw@gmail.com>,
	Vladimir Makarov <vmakarov@redhat.com>,
	 Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [RFC/PATCH] sched: Consider debug insn in no_real_insns_p [PR108273]
Date: Mon, 20 Mar 2023 11:03:07 +0300 (MSK)	[thread overview]
Message-ID: <c26627e4-9bd6-9069-acaa-a51f1fa1c136@ispras.ru> (raw)
In-Reply-To: <928b5bd5-387c-5400-6863-0c045fd22aef@linux.ibm.com>


On Mon, 20 Mar 2023, Kewen.Lin wrote:

> Hi,

Hi. Thank you for the thorough analysis. Since I analyzed
PR108519, I'd like to offer my comments.

> As PR108273 shows, when there is one block which only has
> NOTE_P and LABEL_P insns at non-debug mode while has some
> extra DEBUG_INSN_P insns at debug mode, after scheduling
> it, the DFA states would be different between debug mode
> and non-debug mode.  Since at non-debug mode, the block
> meets no_real_insns_p, it gets skipped; while at debug
> mode, it gets scheduled, even it only has NOTE_P, LABEL_P
> and DEBUG_INSN_P, the call of function advance_one_cycle
> will change the DFA state.  PR108519 also shows this issue
> issue can be exposed by some scheduler changes.

(yes, so an alternative is to avoid extraneous advance_one_cycle
calls, but I think adjusting no_real_insns_p is preferable)

> This patch is to take debug insn into account in function
> no_real_insns_p, which make us not try to schedule for the
> block having only NOTE_P, LABEL_P and DEBUG_INSN_P insns,
> resulting in consistent DFA states between non-debug and
> debug mode.  Changing no_real_insns_p caused ICE when doing
> free_block_dependencies, the root cause is that we create
> dependencies for debug insns, those dependencies are
> expected to be resolved during scheduling insns which gets
> skipped after the change in no_real_insns_p.  By checking
> the code, it looks it's reasonable to skip to compute block
> dependencies for no_real_insns_p blocks.  It can be
> bootstrapped and regtested but it hit one ICE when built
> SPEC2017 bmks at option -O2 -g.  The root cause is that
> initially there are no no_real_insns_p blocks in a region,
> but in the later scheduling one block has one insn scheduled
> speculatively then becomes no_real_insns_p, so we compute
> dependencies and rgn_n_insns for this special block before
> scheduling, later it gets skipped so not scheduled, the
> following counts would mismatch:
> 
>     /* Sanity check: verify that all region insns were scheduled.  */
>       gcc_assert (sched_rgn_n_insns == rgn_n_insns);
> 
> , and we miss to release the allocated dependencies.

Hm, but it is quite normal for BBs to become empty via speculative
scheduling in non-debug mode as well. So I don't think it's the
right way to frame the problem.

I think the main issue here is that debug_insns are "not real insns"
except we add them together with normal insns in the dependency graph,
and then we verify that the graph was exhausted by the scheduler.

We already handle a situation when dbg_cnt is telling the scheduler
to skip blocks. I guess the dbg_cnt handling is broken for a similar
reason?

Can we fix this issue together with the debug_cnt issue by adjusting
dbg_cnt handling in schedule_region, i.e. if no_real_insns_p || !dbg_cnt
then adjust sched_rgn_n_insns and manually resolve+free dependencies?

> To avoid the unexpected mis-matchings, this patch adds one
> bitmap to track this kind of special block which isn't
> no_real_insns_p but becomes no_real_insns_p later, then we
> can adjust the count and free deps for it.

Per above, I hope a simpler solution is possible.

(some comments on the patch below)

> This patch can be bootstrapped and regress-tested on
> x86_64-redhat-linux, aarch64-linux-gnu and
> powerpc64{,le}-linux-gnu.
> 
> I also verified this patch can pass SPEC2017 both intrate
> and fprate bmks building at -g -O2/-O3.
> 
> This is for next stage 1, but since I know little on the
> scheduler, I'd like to post it early for more comments.
> 
> Is it on the right track?  Any thoughts?
> 
> BR,
> Kewen
> -----
> 	PR rtl-optimization/108273
> 
> gcc/ChangeLog:
> 
> 	* haifa-sched.cc (no_real_insns_p): Consider DEBUG_INSN_P insn.
> 	* sched-rgn.cc (no_real_insns): New static bitmap variable.
> 	(compute_block_dependences): Skip for no_real_insns_p.
> 	(free_deps_for_bb_no_real_insns_p): New function.
> 	(free_block_dependencies): Call free_deps_for_bb_no_real_insns_p for
> 	no_real_insns_p bb.
> 	(schedule_region): Fix up sched_rgn_n_insns for some block for which
> 	rgn_n_insns is computed before, and move sched_rgn_local_finish after
> 	free_block_dependencies loop.
> 	(sched_rgn_local_init): Allocate and compute no_real_insns.
> 	(sched_rgn_local_free): Free no_real_insns.
> ---
>  gcc/haifa-sched.cc |  8 ++++-
>  gcc/sched-rgn.cc   | 84 +++++++++++++++++++++++++++++++++++++++++++---
>  2 files changed, 87 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
> index 48b53776fa9..378f3b34cc0 100644
> --- a/gcc/haifa-sched.cc
> +++ b/gcc/haifa-sched.cc
> @@ -5040,7 +5040,13 @@ no_real_insns_p (const rtx_insn *head, const rtx_insn *tail)
>  {
>    while (head != NEXT_INSN (tail))
>      {
> -      if (!NOTE_P (head) && !LABEL_P (head))
> +      /* Take debug insn into account here, otherwise we can have different
> +	 DFA states after scheduling a block which only has NOTE_P, LABEL_P
> +	 and DEBUG_P (debug mode) insns between non-debug and debug modes,
> +	 it could cause -fcompare-debug failure.  */

Sorry, I don't think this comment is appropriate. I'd suggest to rename the
function to no_real_nondebug_insns_p (so when you adjust all callers it
becomes apparent what's affected), and then no comment will be necessary.

> +      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 f2751f62450..211b62e2b4a 100644
> --- a/gcc/sched-rgn.cc
> +++ b/gcc/sched-rgn.cc
> @@ -213,6 +213,11 @@ static int rgn_nr_edges;
>  /* Array of size rgn_nr_edges.  */
>  static edge *rgn_edges;
> 
> +/* For basic block i, the corresponding set bit i in bitmap indicates this basic
> +   block meets predicate no_real_insns_p before scheduling any basic blocks in
> +   the region.  */
> +static bitmap no_real_insns;
> +
>  /* Mapping from each edge in the graph to its number in the rgn.  */
>  #define EDGE_TO_BIT(edge) ((int)(size_t)(edge)->aux)
>  #define SET_EDGE_TO_BIT(edge,nr) ((edge)->aux = (void *)(size_t)(nr))
> @@ -2730,6 +2735,15 @@ compute_block_dependences (int bb)
>    gcc_assert (EBB_FIRST_BB (bb) == EBB_LAST_BB (bb));
>    get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), &head, &tail);
> 
> +  /* Don't compute block dependencies if there are no real insns.  */
> +  if (no_real_insns_p (head, tail))
> +    {
> +      if (current_nr_blocks > 1)
> +	propagate_deps (bb, &tmp_deps);
> +      free_deps (&tmp_deps);
> +      return;
> +    }
> +
>    sched_analyze (&tmp_deps, head, tail);
> 
>    add_branch_dependences (head, tail);
> @@ -2744,6 +2758,42 @@ compute_block_dependences (int bb)
>      targetm.sched.dependencies_evaluation_hook (head, tail);
>  }
> 
> +/* The basic block without any real insns (no_real_insns_p) would be
> +   skipped in compute_block_dependences, so for most no_real_insns_p
> +   basic block, we don't need to free dependencies for them.  But
> +   sometimes some basic block which isn't no_real_insns_p before
> +   scheduling can become no_real_insns_p with speculative scheduling,
> +   so we still need to free dependencies computed early for it.  So
> +   this function is to free dependencies if need.  */

Please try to keep comments more concise. The following might have been
more appropriate:

/* Artificially resolve and free dependencies for instructions HEAD to TAIL.  */

and the explanation why we are doing that would go to the caller.

> +
> +static void
> +free_deps_for_bb_no_real_insns_p (rtx_insn *head, rtx_insn *tail, int bb)
> +{
> +  gcc_assert (no_real_insns_p (head, tail));
> +
> +  /* Don't bother if there is only one block.  */
> +  if (current_nr_blocks == 1)
> +    return;

Sorry, can you explain this check?

> +
> +  /* We don't compute dependencies before.  */
> +  if (bitmap_bit_p (no_real_insns, bb))
> +    return;

This looks more appropriate to check in the caller.

Alexander

> +
> +  rtx_insn *insn;
> +  rtx_insn *next_tail = NEXT_INSN (tail);
> +  sd_iterator_def sd_it;
> +  dep_t dep;
> +
> +  /* There could be some insns which get skipped in scheduling but we
> +     compute dependencies for them previously, so make them resolved.  */
> +  for (insn = head; insn != next_tail; insn = NEXT_INSN (insn))
> +    for (sd_it = sd_iterator_start (insn, SD_LIST_FORW);
> +	 sd_iterator_cond (&sd_it, &dep);)
> +      sd_resolve_dep (sd_it);
> +
> +  sched_free_deps (head, tail, true);
> +}
> +
>  /* Free dependencies of instructions inside BB.  */
>  static void
>  free_block_dependencies (int bb)
> @@ -2754,7 +2804,10 @@ free_block_dependencies (int bb)
>    get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), &head, &tail);
> 
>    if (no_real_insns_p (head, tail))
> -    return;
> +    {
> +      free_deps_for_bb_no_real_insns_p (head, tail, bb);
> +      return;
> +    }
> 
>    sched_free_deps (head, tail, true);
>  }
> @@ -3177,6 +3230,18 @@ schedule_region (int rgn)
>  	{
>  	  gcc_assert (first_bb == last_bb);
>  	  save_state_for_fallthru_edge (last_bb, bb_state[first_bb->index]);
> +	  /* We have counted this block when computing rgn_n_insns
> +	     previously, so need to fix up sched_rgn_n_insns if we
> +	     skip this.  */
> +	  if (current_nr_blocks > 1 && !bitmap_bit_p (no_real_insns, bb))
> +	    {
> +	      while (head != NEXT_INSN (tail))
> +		{
> +		  if (INSN_P (head))
> +		    sched_rgn_n_insns++;
> +		  head = NEXT_INSN (head);
> +		}
> +	    }
>  	  continue;
>  	}
> 
> @@ -3218,13 +3283,13 @@ schedule_region (int rgn)
> 
>    sched_finish_ready_list ();
> 
> -  /* Done with this region.  */
> -  sched_rgn_local_finish ();
> -
>    /* Free dependencies.  */
>    for (bb = 0; bb < current_nr_blocks; ++bb)
>      free_block_dependencies (bb);
> 
> +  /* Done with this region.  */
> +  sched_rgn_local_finish ();
> +
>    gcc_assert (haifa_recovery_bb_ever_added_p
>  	      || deps_pools_are_empty_p ());
>  }
> @@ -3444,6 +3509,16 @@ sched_rgn_local_init (int rgn)
>  	  FOR_EACH_EDGE (e, ei, block->succs)
>  	    e->aux = NULL;
>          }
> +
> +      /* Compute no_real_insns.  */
> +      no_real_insns = BITMAP_ALLOC (NULL);
> +      for (bb = 0; bb < current_nr_blocks; bb++)
> +	{
> +	  rtx_insn *head, *tail;
> +	  get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), &head, &tail);
> +	  if (no_real_insns_p (head, tail))
> +	    bitmap_set_bit (no_real_insns, bb);
> +	}
>      }
>  }
> 
> @@ -3456,6 +3531,7 @@ sched_rgn_local_free (void)
>    sbitmap_vector_free (pot_split);
>    sbitmap_vector_free (ancestor_edges);
>    free (rgn_edges);
> +  BITMAP_FREE (no_real_insns);
>  }
> 
>  /* Free data computed for the finished region.  */
> --
> 2.39.1
> 

  reply	other threads:[~2023-03-20  8:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  6:31 Kewen.Lin
2023-03-20  8:03 ` Alexander Monakov [this message]
2023-03-20  9:48   ` Kewen.Lin
2023-03-29  7:18     ` [PATCH v2] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273] Kewen.Lin
2023-05-17  6:20       ` Kewen.Lin
2023-06-15  6:39         ` PING^2 " Kewen.Lin
2023-08-07 10:07           ` PING^3 " Kewen.Lin

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=c26627e4-9bd6-9069-acaa-a51f1fa1c136@ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=linkw@linux.ibm.com \
    --cc=richard.guenther@gmail.com \
    --cc=richard.sandiford@arm.com \
    --cc=segher@kernel.crashing.org \
    --cc=vmakarov@redhat.com \
    /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: link
Be 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).