From: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
To: Christophe Lyon <Christophe.Lyon@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Richard Sandiford <Richard.Sandiford@arm.com>
Cc: Christophe Lyon <Christophe.Lyon@arm.com>
Subject: RE: [PATCH 06/22] arm: [MVE intrinsics] add unspec_based_mve_function_exact_insn
Date: Tue, 2 May 2023 16:17:23 +0000 [thread overview]
Message-ID: <PAXPR08MB692609CA85E571C0532A4B47936F9@PAXPR08MB6926.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20230418134608.244751-7-christophe.lyon@arm.com>
> -----Original Message-----
> From: Christophe Lyon <christophe.lyon@arm.com>
> Sent: Tuesday, April 18, 2023 2:46 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>;
> Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
> <Richard.Sandiford@arm.com>
> Cc: Christophe Lyon <Christophe.Lyon@arm.com>
> Subject: [PATCH 06/22] arm: [MVE intrinsics] add
> unspec_based_mve_function_exact_insn
>
> Introduce a function that will be used to build intrinsics which use
> RTX codes for the non-predicated, no-mode version, and UNSPECS
> otherwise.
>
Ok.
Thanks,
Kyrill
> 2022-09-08 Christophe Lyon <christophe.lyon@arm.com>
>
> gcc/ChangeLog:
>
> * config/arm/arm-mve-builtins-functions.h (class
> unspec_based_mve_function_base): New.
> (class unspec_based_mve_function_exact_insn): New.
> ---
> gcc/config/arm/arm-mve-builtins-functions.h | 186 ++++++++++++++++++++
> 1 file changed, 186 insertions(+)
>
> diff --git a/gcc/config/arm/arm-mve-builtins-functions.h
> b/gcc/config/arm/arm-mve-builtins-functions.h
> index dff01999bcd..6d992b270b0 100644
> --- a/gcc/config/arm/arm-mve-builtins-functions.h
> +++ b/gcc/config/arm/arm-mve-builtins-functions.h
> @@ -39,6 +39,192 @@ public:
> }
> };
>
> +/* An incomplete function_base for functions that have an associated
> + rtx_code for signed integers, unsigned integers and floating-point
> + values for the non-predicated, non-suffixed intrinsic, and unspec
> + codes, with separate codes for signed integers, unsigned integers
> + and floating-point values. The class simply records information
> + about the mapping for derived classes to use. */
> +class unspec_based_mve_function_base : public function_base
> +{
> +public:
> + CONSTEXPR unspec_based_mve_function_base (rtx_code code_for_sint,
> + rtx_code code_for_uint,
> + rtx_code code_for_fp,
> + int unspec_for_n_sint,
> + int unspec_for_n_uint,
> + int unspec_for_n_fp,
> + int unspec_for_m_sint,
> + int unspec_for_m_uint,
> + int unspec_for_m_fp,
> + int unspec_for_m_n_sint,
> + int unspec_for_m_n_uint,
> + int unspec_for_m_n_fp)
> + : m_code_for_sint (code_for_sint),
> + m_code_for_uint (code_for_uint),
> + m_code_for_fp (code_for_fp),
> + m_unspec_for_n_sint (unspec_for_n_sint),
> + m_unspec_for_n_uint (unspec_for_n_uint),
> + m_unspec_for_n_fp (unspec_for_n_fp),
> + m_unspec_for_m_sint (unspec_for_m_sint),
> + m_unspec_for_m_uint (unspec_for_m_uint),
> + m_unspec_for_m_fp (unspec_for_m_fp),
> + m_unspec_for_m_n_sint (unspec_for_m_n_sint),
> + m_unspec_for_m_n_uint (unspec_for_m_n_uint),
> + m_unspec_for_m_n_fp (unspec_for_m_n_fp)
> + {}
> +
> + /* The rtx code to use for signed, unsigned integers and
> + floating-point values respectively. */
> + rtx_code m_code_for_sint;
> + rtx_code m_code_for_uint;
> + rtx_code m_code_for_fp;
> +
> + /* The unspec code associated with signed-integer, unsigned-integer
> + and floating-point operations respectively. It covers the cases
> + with the _n suffix, and/or the _m predicate. */
> + int m_unspec_for_n_sint;
> + int m_unspec_for_n_uint;
> + int m_unspec_for_n_fp;
> + int m_unspec_for_m_sint;
> + int m_unspec_for_m_uint;
> + int m_unspec_for_m_fp;
> + int m_unspec_for_m_n_sint;
> + int m_unspec_for_m_n_uint;
> + int m_unspec_for_m_n_fp;
> +};
> +
> +/* Map the function directly to CODE (UNSPEC, M) where M is the vector
> + mode associated with type suffix 0, except when there is no
> + predicate and no _n suffix, in which case we use the appropriate
> + rtx_code. This is useful when the basic operation is mapped to a
> + standard RTX code and all other versions use different unspecs. */
> +class unspec_based_mve_function_exact_insn : public
> unspec_based_mve_function_base
> +{
> +public:
> + CONSTEXPR unspec_based_mve_function_exact_insn (rtx_code
> code_for_sint,
> + rtx_code code_for_uint,
> + rtx_code code_for_fp,
> + int unspec_for_n_sint,
> + int unspec_for_n_uint,
> + int unspec_for_n_fp,
> + int unspec_for_m_sint,
> + int unspec_for_m_uint,
> + int unspec_for_m_fp,
> + int unspec_for_m_n_sint,
> + int unspec_for_m_n_uint,
> + int unspec_for_m_n_fp)
> + : unspec_based_mve_function_base (code_for_sint,
> + code_for_uint,
> + code_for_fp,
> + unspec_for_n_sint,
> + unspec_for_n_uint,
> + unspec_for_n_fp,
> + unspec_for_m_sint,
> + unspec_for_m_uint,
> + unspec_for_m_fp,
> + unspec_for_m_n_sint,
> + unspec_for_m_n_uint,
> + unspec_for_m_n_fp)
> + {}
> +
> + rtx
> + expand (function_expander &e) const override
> + {
> + /* No suffix, no predicate, use the right RTX code. */
> + if ((e.mode_suffix_id != MODE_n)
> + && (e.pred == PRED_none))
> + return e.map_to_rtx_codes (m_code_for_sint, m_code_for_uint,
> + m_code_for_fp);
> +
> + insn_code code;
> + switch (e.pred)
> + {
> + case PRED_none:
> + if (e.mode_suffix_id == MODE_n)
> + /* No predicate, _n suffix. */
> + {
> + if (e.type_suffix (0).integer_p)
> + if (e.type_suffix (0).unsigned_p)
> + code = code_for_mve_q_n (m_unspec_for_n_uint,
> m_unspec_for_n_uint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_n (m_unspec_for_n_sint,
> m_unspec_for_n_sint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_n_f (m_unspec_for_n_fp, e.vector_mode
> (0));
> +
> + return e.use_exact_insn (code);
> + }
> + gcc_unreachable ();
> + break;
> +
> + case PRED_m:
> + switch (e.mode_suffix_id)
> + {
> + case MODE_none:
> + /* No suffix, "m" predicate. */
> + if (e.type_suffix (0).integer_p)
> + if (e.type_suffix (0).unsigned_p)
> + code = code_for_mve_q_m (m_unspec_for_m_uint,
> m_unspec_for_m_uint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m (m_unspec_for_m_sint,
> m_unspec_for_m_sint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_f (m_unspec_for_m_fp,
> e.vector_mode (0));
> + break;
> +
> + case MODE_n:
> + /* _n suffix, "m" predicate. */
> + if (e.type_suffix (0).integer_p)
> + if (e.type_suffix (0).unsigned_p)
> + code = code_for_mve_q_m_n (m_unspec_for_m_n_uint,
> m_unspec_for_m_n_uint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_n (m_unspec_for_m_n_sint,
> m_unspec_for_m_n_sint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_n_f (m_unspec_for_m_n_fp,
> e.vector_mode (0));
> + break;
> +
> + default:
> + gcc_unreachable ();
> + }
> + return e.use_cond_insn (code, 0);
> +
> + case PRED_x:
> + switch (e.mode_suffix_id)
> + {
> + case MODE_none:
> + /* No suffix, "x" predicate. */
> + if (e.type_suffix (0).integer_p)
> + if (e.type_suffix (0).unsigned_p)
> + code = code_for_mve_q_m (m_unspec_for_m_uint,
> m_unspec_for_m_uint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m (m_unspec_for_m_sint,
> m_unspec_for_m_sint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_f (m_unspec_for_m_fp,
> e.vector_mode (0));
> + break;
> +
> + case MODE_n:
> + /* _n suffix, "x" predicate. */
> + if (e.type_suffix (0).integer_p)
> + if (e.type_suffix (0).unsigned_p)
> + code = code_for_mve_q_m_n (m_unspec_for_m_n_uint,
> m_unspec_for_m_n_uint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_n (m_unspec_for_m_n_sint,
> m_unspec_for_m_n_sint, e.vector_mode (0));
> + else
> + code = code_for_mve_q_m_n_f (m_unspec_for_m_n_fp,
> e.vector_mode (0));
> + break;
> +
> + default:
> + gcc_unreachable ();
> + }
> + return e.use_pred_x_insn (code);
> +
> + default:
> + gcc_unreachable ();
> + }
> +
> + gcc_unreachable ();
> + }
> +};
> +
> } /* end namespace arm_mve */
>
> /* Declare the global function base NAME, creating it from an instance
> --
> 2.34.1
next prev parent reply other threads:[~2023-05-02 16:17 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 13:45 [PATCH 00/22] arm: New framework for MVE intrinsics Christophe Lyon
2023-04-18 13:45 ` [PATCH 01/22] arm: move builtin function codes into general numberspace Christophe Lyon
2023-05-02 9:24 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 02/22] arm: [MVE intrinsics] Add new framework Christophe Lyon
2023-05-02 10:17 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq Christophe Lyon
2023-05-02 10:26 ` Kyrylo Tkachov
2023-05-02 14:05 ` Christophe Lyon
2023-05-02 15:28 ` Kyrylo Tkachov
2023-05-02 15:49 ` Christophe Lyon
2023-05-03 14:37 ` [PATCH v2 " Christophe Lyon
2023-05-03 14:52 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 04/22] arm: [MVE intrinsics] Rework vuninitialized Christophe Lyon
2023-05-02 16:13 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 05/22] arm: [MVE intrinsics] add binary_opt_n shape Christophe Lyon
2023-05-02 16:16 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 06/22] arm: [MVE intrinsics] add unspec_based_mve_function_exact_insn Christophe Lyon
2023-05-02 16:17 ` Kyrylo Tkachov [this message]
2023-04-18 13:45 ` [PATCH 07/22] arm: [MVE intrinsics] factorize vadd vsubq vmulq Christophe Lyon
2023-05-02 16:19 ` Kyrylo Tkachov
2023-05-02 16:22 ` Christophe Lyon
2023-04-18 13:45 ` [PATCH 08/22] arm: [MVE intrinsics] rework vaddq vmulq vsubq Christophe Lyon
2023-05-02 16:31 ` Kyrylo Tkachov
2023-05-03 9:06 ` Christophe Lyon
2023-04-18 13:45 ` [PATCH 09/22] arm: [MVE intrinsics] add binary shape Christophe Lyon
2023-05-02 16:32 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 10/22] arm: [MVE intrinsics] factorize vandq veorq vorrq vbicq Christophe Lyon
2023-05-02 16:36 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 11/22] arm: [MVE intrinsics] rework vandq veorq Christophe Lyon
2023-05-02 16:37 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 12/22] arm: [MVE intrinsics] add binary_orrq shape Christophe Lyon
2023-05-02 16:39 ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 13/22] arm: [MVE intrinsics] rework vorrq Christophe Lyon
2023-05-02 16:41 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 14/22] arm: [MVE intrinsics] add unspec_mve_function_exact_insn Christophe Lyon
2023-05-03 8:40 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 15/22] arm: [MVE intrinsics] add create shape Christophe Lyon
2023-05-03 8:40 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 16/22] arm: [MVE intrinsics] factorize vcreateq Christophe Lyon
2023-05-03 8:42 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 17/22] arm: [MVE intrinsics] rework vcreateq Christophe Lyon
2023-05-03 8:44 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 18/22] arm: [MVE intrinsics] factorize several binary_m operations Christophe Lyon
2023-05-03 8:46 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 19/22] arm: [MVE intrinsics] factorize several binary _n operations Christophe Lyon
2023-05-03 8:47 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 20/22] arm: [MVE intrinsics] factorize several binary _m_n operations Christophe Lyon
2023-05-03 8:48 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 21/22] arm: [MVE intrinsics] factorize several binary operations Christophe Lyon
2023-05-03 8:49 ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 22/22] arm: [MVE intrinsics] rework vhaddq vhsubq vmulhq vqaddq vqsubq vqdmulhq vrhaddq vrmulhq Christophe Lyon
2023-05-03 8:51 ` Kyrylo Tkachov
2023-05-02 9:18 ` [PATCH 00/22] arm: New framework for MVE intrinsics Kyrylo Tkachov
2023-05-02 15:04 ` Christophe Lyon
2023-05-03 15:01 ` Christophe Lyon
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=PAXPR08MB692609CA85E571C0532A4B47936F9@PAXPR08MB6926.eurprd08.prod.outlook.com \
--to=kyrylo.tkachov@arm.com \
--cc=Christophe.Lyon@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Richard.Sandiford@arm.com \
--cc=gcc-patches@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: 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).