From: Richard Sandiford <richard.sandiford@arm.com>
To: Stamatis Markianos-Wright <stam.markianos-wright@arm.com>
Cc: "Andre Vieira \(lists\)" <andre.simoesdiasvieira@arm.com>,
Stamatis Markianos-Wright via Gcc-patches
<gcc-patches@gcc.gnu.org>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
Subject: Re: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops
Date: Sat, 09 Dec 2023 18:31:59 +0000 [thread overview]
Message-ID: <mpto7ezrzvk.fsf@arm.com> (raw)
In-Reply-To: <8000eb76-0abf-45db-92c1-d307ac8fccfc@arm.com> (Stamatis Markianos-Wright's message of "Thu, 30 Nov 2023 12:55:57 +0000")
Sorry for the slow review.
Stamatis Markianos-Wright <stam.markianos-wright@arm.com> writes:
> [...]
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index 44a04b86cb5806fcf50917826512fd203d42106c..c083f965fa9a40781bc86beb6e63654afd14eac4 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -6922,23 +6922,24 @@
> ;; Originally expanded by 'predicated_doloop_end'.
> ;; In the rare situation where the branch is too far, we do also need to
> ;; revert FPSCR.LTPSIZE back to 0x100 after the last iteration.
> -(define_insn "*predicated_doloop_end_internal"
> +(define_insn "predicated_doloop_end_internal<letp_num_lanes>"
> [(set (pc)
> (if_then_else
> - (ge (plus:SI (reg:SI LR_REGNUM)
> - (match_operand:SI 0 "const_int_operand" ""))
> - (const_int 0))
> - (label_ref (match_operand 1 "" ""))
> + (gtu (unspec:SI [(plus:SI (match_operand:SI 0 "s_register_operand" "=r")
> + (const_int <letp_num_lanes_neg>))]
> + LETP)
> + (const_int <letp_num_lanes_minus_1>))
Is there any need for the unspec? I couldn't see why this wasn't simply:
(gtu (match_operand:SI 0 "s_register_operand" "=r")
(const_int <letp_num_lanes_minus_1>))
But I agree that using gtu rather than ge is nicer if it's what the
instruction does.
> diff --git a/gcc/df-core.cc b/gcc/df-core.cc
> index d4812b04a7cb97ea1606082e26e910472da5bcc1..4fcc14bf790d43e792b3c926fe1f80073d908c17 100644
> --- a/gcc/df-core.cc
> +++ b/gcc/df-core.cc
> @@ -1964,6 +1964,21 @@ df_bb_regno_last_def_find (basic_block bb, unsigned int regno)
> return NULL;
> }
>
> +/* Return the one and only def of REGNO within BB. If there is no def or
> + there are multiple defs, return NULL. */
> +
> +df_ref
> +df_bb_regno_only_def_find (basic_block bb, unsigned int regno)
> +{
> + df_ref temp = df_bb_regno_first_def_find (bb, regno);
> + if (!temp)
> + return NULL;
> + else if (temp == df_bb_regno_last_def_find (bb, regno))
> + return temp;
> + else
> + return NULL;
> +}
> +
> /* Finds the reference corresponding to the definition of REG in INSN.
> DF is the dataflow object. */
>
> diff --git a/gcc/df.h b/gcc/df.h
> index 402657a7076f1bcad24e9c50682e033e57f432f9..98623637f9c839c799222e99df2a7173a770b2ac 100644
> --- a/gcc/df.h
> +++ b/gcc/df.h
> @@ -987,6 +987,7 @@ extern void df_check_cfg_clean (void);
> #endif
> extern df_ref df_bb_regno_first_def_find (basic_block, unsigned int);
> extern df_ref df_bb_regno_last_def_find (basic_block, unsigned int);
> +extern df_ref df_bb_regno_only_def_find (basic_block, unsigned int);
> extern df_ref df_find_def (rtx_insn *, rtx);
> extern bool df_reg_defined (rtx_insn *, rtx);
> extern df_ref df_find_use (rtx_insn *, rtx);
> diff --git a/gcc/loop-doloop.cc b/gcc/loop-doloop.cc
> index 4feb0a25ab9331b7124df900f73c9fc6fb3eb10b..d919207505c472c8a54a2c9c982a09061584177b 100644
> --- a/gcc/loop-doloop.cc
> +++ b/gcc/loop-doloop.cc
> @@ -85,10 +85,10 @@ doloop_condition_get (rtx_insn *doloop_pat)
> forms:
>
> 1) (parallel [(set (pc) (if_then_else (condition)
> - (label_ref (label))
> - (pc)))
> - (set (reg) (plus (reg) (const_int -1)))
> - (additional clobbers and uses)])
> + (label_ref (label))
> + (pc)))
> + (set (reg) (plus (reg) (const_int -1)))
> + (additional clobbers and uses)])
>
> The branch must be the first entry of the parallel (also required
> by jump.cc), and the second entry of the parallel must be a set of
> @@ -96,19 +96,34 @@ doloop_condition_get (rtx_insn *doloop_pat)
> the loop counter in an if_then_else too.
>
> 2) (set (reg) (plus (reg) (const_int -1))
> - (set (pc) (if_then_else (reg != 0)
> - (label_ref (label))
> - (pc))).
> + (set (pc) (if_then_else (reg != 0)
> + (label_ref (label))
> + (pc))).
>
> Some targets (ARM) do the comparison before the branch, as in the
> following form:
>
> - 3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
> - (set (reg) (plus (reg) (const_int -1)))])
> - (set (pc) (if_then_else (cc == NE)
> - (label_ref (label))
> - (pc))) */
> -
> + 3) (parallel [(set (cc) (compare (plus (reg) (const_int -1)) 0))
> + (set (reg) (plus (reg) (const_int -1)))])
> + (set (pc) (if_then_else (cc == NE)
> + (label_ref (label))
> + (pc)))
> +
> + The ARM target also supports a special case of a counter that decrements
> + by `n` and terminating in a GTU condition. In that case, the compare and
> + branch are all part of one insn, containing an UNSPEC:
> +
> + 4) (parallel [
> + (set (pc)
> + (if_then_else (gtu (unspec:SI [(plus:SI (reg:SI 14 lr)
> + (const_int -n))])
> + (const_int n-1]))
Similarly here.
> + (label_ref)
> + (pc)))
> + (set (reg:SI 14 lr)
> + (plus:SI (reg:SI 14 lr)
> + (const_int -n)))
> + */
> pattern = PATTERN (doloop_pat);
>
> if (GET_CODE (pattern) != PARALLEL)
> @@ -143,7 +158,7 @@ doloop_condition_get (rtx_insn *doloop_pat)
> || GET_CODE (cmp_arg1) != PLUS)
> return 0;
> reg_orig = XEXP (cmp_arg1, 0);
> - if (XEXP (cmp_arg1, 1) != GEN_INT (-1)
> + if (XEXP (cmp_arg1, 1) != GEN_INT (-1)
> || !REG_P (reg_orig))
> return 0;
> cc_reg = SET_DEST (cmp_orig);
> @@ -173,15 +188,17 @@ doloop_condition_get (rtx_insn *doloop_pat)
> if (! REG_P (reg))
> return 0;
>
> - /* Check if something = (plus (reg) (const_int -1)).
> + /* Check if something = (plus (reg) (const_int -n)).
> On IA-64, this decrement is wrapped in an if_then_else. */
> inc_src = SET_SRC (inc);
> if (GET_CODE (inc_src) == IF_THEN_ELSE)
> inc_src = XEXP (inc_src, 1);
> if (GET_CODE (inc_src) != PLUS
> || XEXP (inc_src, 0) != reg
> - || XEXP (inc_src, 1) != constm1_rtx)
> + || !CONST_INT_P (XEXP (inc_src, 1))
> + || INTVAL (XEXP (inc_src, 1)) >= 0)
> return 0;
> + int dec_num = abs (INTVAL (XEXP (inc_src, 1)));
>
> /* Check for (set (pc) (if_then_else (condition)
> (label_ref (label))
> @@ -196,60 +213,71 @@ doloop_condition_get (rtx_insn *doloop_pat)
> /* Extract loop termination condition. */
> condition = XEXP (SET_SRC (cmp), 0);
>
> - /* We expect a GE or NE comparison with 0 or 1. */
> - if ((GET_CODE (condition) != GE
> - && GET_CODE (condition) != NE)
> - || (XEXP (condition, 1) != const0_rtx
> - && XEXP (condition, 1) != const1_rtx))
> + /* We expect a GE or NE comparison with 0 or 1, or a GTU comparison with
> + dec_num - 1. */
> + if (!((GET_CODE (condition) == GE
> + || GET_CODE (condition) == NE)
> + && (XEXP (condition, 1) == const0_rtx
> + || XEXP (condition, 1) == const1_rtx ))
> + &&!(GET_CODE (condition) == GTU
> + && ((INTVAL (XEXP (condition, 1))) == (dec_num - 1))))
> return 0;
Formatting nit: should be:
/* We expect a GE or NE comparison with 0 or 1, or a GTU comparison with
dec_num */
if (!((GET_CODE (condition) == GE
|| GET_CODE (condition) == NE)
&& (XEXP (condition, 1) == const0_rtx
|| XEXP (condition, 1) == const1_rtx))
&& !(GET_CODE (condition) == GTU
&& CONST_INT_P (XEXP (condition, 1))
&& INTVAL (XEXP (condition, 1)) == dec_num - 1))
return 0;
>
> - if ((XEXP (condition, 0) == reg)
> + /* For the ARM special case of having a GTU: re-form the condition without
> + the unspec for the benefit of the middle-end. */
> + if (GET_CODE (condition) == GTU)
> + {
> + condition = gen_rtx_fmt_ee (GTU, VOIDmode, inc_src,
> + GEN_INT (dec_num - 1));
> + return condition;
> + }
Hopefully the gen_rtx_fmt_ee wouldn't be needed then. It should just
be enough to return the original condition.
OK for the target-independent parts with those changed if you agree.
Thanks,
Richard
next prev parent reply other threads:[~2023-12-09 18:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 10:31 [PATCH " Stamatis Markianos-Wright
2023-09-06 17:19 ` [PING][PATCH " Stamatis Markianos-Wright
2023-09-14 12:10 ` Kyrylo Tkachov
2023-09-28 12:51 ` Andre Vieira (lists)
2023-10-11 11:34 ` Stamatis Markianos-Wright
2023-10-23 10:16 ` Andre Vieira (lists)
2023-10-24 15:11 ` Richard Sandiford
2023-11-06 11:03 ` Stamatis Markianos-Wright
2023-11-06 11:24 ` Richard Sandiford
2023-11-06 17:29 ` Stamatis Markianos-Wright
2023-11-10 12:41 ` Stamatis Markianos-Wright
2023-11-16 11:36 ` Stamatis Markianos-Wright
2023-11-27 12:47 ` Andre Vieira (lists)
2023-11-30 12:55 ` Stamatis Markianos-Wright
2023-12-07 18:08 ` Andre Vieira (lists)
2023-12-09 18:31 ` Richard Sandiford [this message]
2023-12-12 17:56 ` Richard Earnshaw
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=mpto7ezrzvk.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=Kyrylo.Tkachov@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=andre.simoesdiasvieira@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=stam.markianos-wright@arm.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).