public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Jin Ma via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Jin Ma <jinma@linux.alibaba.com>,
	 "kito.cheng\@sifive.com" <kito.cheng@sifive.com>,
	 "kito.cheng\@gmail.com" <kito.cheng@gmail.com>,
	 "palmer\@dabbelt.com" <palmer@dabbelt.com>,
	 "jeffreyalaw\@gmail.com" <jeffreyalaw@gmail.com>,
	 "ijinma\@yeah.net" <ijinma@yeah.net>
Subject: Re: [PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) at the latest to issue.
Date: Mon, 27 Mar 2023 18:01:15 +0100	[thread overview]
Message-ID: <mpta5zyw2lg.fsf@arm.com> (raw)
In-Reply-To: <20230323080734.423-1-jinma@linux.alibaba.com> (Jin Ma via Gcc-patches's message of "Thu, 23 Mar 2023 08:07:34 +0000")

Jin Ma via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>   Unrecog insns (such as CLOBBER, USE) does not represent real instructions, but in the
> process of pipeline optimization, they will wait for transmission in ready list like
> other insns, without considering resource conflicts and cycles. This results in a
> multi-issue CPU architecture that can be issued at any time if other regular insns
> have resource conflicts or cannot be launched for other reasons. As a result, its
> position is advanced in the generated insns sequence, which will affect register
> allocation and often lead to more redundant mov instructions.

Is it the clobber rather than the use case that is causing problems?
I would expect that scheduling a use ASAP would be better for register
pressure, since it might close off the associated live range and so
reduce the number of conflicts.

I.e. is the problem that, when a live range starts with a clobber,
the current code will tend to move the clobber up and so extend
the associated live range?  If so, that sounds like something we
should address more directly, for two reasons:

(1) We should try to prevent clobbers that start a live range from being
    moved up even if first_cycle_insn_p.

(2) Clobbers can also be used to close off a live range, which is useful
    if a pseudo is only written to in parts.  The current behaviour is
    probably better for those clobbers.

In general, if you're hitting register pressure problems with scheduling,
have you tried enabling -fsched-pressure by default, possibly with
--param=sched-pressure-algorithm=2 (but try with the default algo too)?

Thanks,
Richard

>
> gcc/ChangeLog:
>
> 	* haifa-sched.cc (prune_ready_list): Consider unrecog insns(CLOBBER and USE)
> 	in pruning ready lists.

> ---
>  gcc/haifa-sched.cc | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
> index 48b53776fa9..72c4c44da76 100644
> --- a/gcc/haifa-sched.cc
> +++ b/gcc/haifa-sched.cc
> @@ -6318,6 +6318,14 @@ prune_ready_list (state_t temp_state, bool first_cycle_insn_p,
>  	      cost = 1;
>  	      reason = "not a shadow";
>  	    }
> +	  else if (recog_memoized (insn) < 0
> +		  && (GET_CODE (PATTERN (insn)) == CLOBBER
> +		  || GET_CODE (PATTERN (insn)) == USE))
> +	    {
> +	      if (!first_cycle_insn_p)
> +		cost = 1;
> +	      reason = "unrecog insn";
> +	    }
>  	  else if (recog_memoized (insn) < 0)
>  	    {
>  	      if (!first_cycle_insn_p

  reply	other threads:[~2023-03-27 17:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  8:07 [PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER,USE) " Jin Ma
2023-03-27 17:01 ` Richard Sandiford [this message]
2023-04-14 21:38   ` [PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) " Jeff Law
2023-05-29 10:51     ` [PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range Jin Ma
2023-06-08  1:50       ` Jin Ma
2023-06-09 23:40       ` Jeff Law
2023-06-12  3:38         ` Jin Ma
2023-11-11 18:51           ` Jeff Law
2023-08-14 11:22         ` [PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it starts a new " Jin Ma
2023-08-29  8:00           ` Jin Ma
2023-11-11 20:12           ` Jeff Law
2023-11-12 17:41             ` Xi Ruoyao
2023-11-12 18:02               ` Jeff Law
2023-11-12 18:11                 ` Xi Ruoyao
2023-11-13  2:16                 ` Jin Ma
2023-11-13  2:28                   ` Jeff Law

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=mpta5zyw2lg.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ijinma@yeah.net \
    --cc=jeffreyalaw@gmail.com \
    --cc=jinma@linux.alibaba.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=palmer@dabbelt.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).