From: Richard Sandiford <richard.sandiford@arm.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 15/21] aarch64: Generalise unspec_based_function_base
Date: Fri, 17 Nov 2023 17:27:24 +0000 [thread overview]
Message-ID: <mptbkbss32b.fsf@arm.com> (raw)
In-Reply-To: <mpt4jhkuwdr.fsf@arm.com> (Richard Sandiford's message of "Fri, 17 Nov 2023 17:23:28 +0000")
Until now, SVE intrinsics that map directly to unspecs
have always used type suffix 0 to distinguish between signed
integers, unsigned integers, and floating-point values.
SME adds functions that need to use type suffix 1 instead.
This patch generalises the classes accordingly.
gcc/
* config/aarch64/aarch64-sve-builtins-functions.h
(unspec_based_function_base): Allow type suffix 1 to determine
the mode of the operation.
(unspec_based_function): Update accordingly.
(unspec_based_fused_function): Likewise.
(unspec_based_fused_lane_function): Likewise.
---
.../aarch64/aarch64-sve-builtins-functions.h | 29 ++++++++++++-------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-sve-builtins-functions.h b/gcc/config/aarch64/aarch64-sve-builtins-functions.h
index 4a10102038a..be2561620f4 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins-functions.h
+++ b/gcc/config/aarch64/aarch64-sve-builtins-functions.h
@@ -234,18 +234,21 @@ class unspec_based_function_base : public function_base
public:
CONSTEXPR unspec_based_function_base (int unspec_for_sint,
int unspec_for_uint,
- int unspec_for_fp)
+ int unspec_for_fp,
+ unsigned int suffix_index = 0)
: m_unspec_for_sint (unspec_for_sint),
m_unspec_for_uint (unspec_for_uint),
- m_unspec_for_fp (unspec_for_fp)
+ m_unspec_for_fp (unspec_for_fp),
+ m_suffix_index (suffix_index)
{}
/* Return the unspec code to use for INSTANCE, based on type suffix 0. */
int
unspec_for (const function_instance &instance) const
{
- return (!instance.type_suffix (0).integer_p ? m_unspec_for_fp
- : instance.type_suffix (0).unsigned_p ? m_unspec_for_uint
+ auto &suffix = instance.type_suffix (m_suffix_index);
+ return (!suffix.integer_p ? m_unspec_for_fp
+ : suffix.unsigned_p ? m_unspec_for_uint
: m_unspec_for_sint);
}
@@ -254,6 +257,9 @@ public:
int m_unspec_for_sint;
int m_unspec_for_uint;
int m_unspec_for_fp;
+
+ /* Which type suffix is used to choose between the unspecs. */
+ unsigned int m_suffix_index;
};
/* A function_base for functions that have an associated unspec code.
@@ -306,7 +312,8 @@ public:
rtx
expand (function_expander &e) const override
{
- return e.use_exact_insn (CODE (unspec_for (e), e.vector_mode (0)));
+ return e.use_exact_insn (CODE (unspec_for (e),
+ e.vector_mode (m_suffix_index)));
}
};
@@ -360,16 +367,16 @@ public:
{
int unspec = unspec_for (e);
insn_code icode;
- if (e.type_suffix (0).float_p)
+ if (e.type_suffix (m_suffix_index).float_p)
{
/* Put the operands in the normal (fma ...) order, with the accumulator
last. This fits naturally since that's also the unprinted operand
in the asm output. */
e.rotate_inputs_left (0, e.pred != PRED_none ? 4 : 3);
- icode = code_for_aarch64_sve (unspec, e.vector_mode (0));
+ icode = code_for_aarch64_sve (unspec, e.vector_mode (m_suffix_index));
}
else
- icode = INT_CODE (unspec, e.vector_mode (0));
+ icode = INT_CODE (unspec, e.vector_mode (m_suffix_index));
return e.use_exact_insn (icode);
}
};
@@ -390,16 +397,16 @@ public:
{
int unspec = unspec_for (e);
insn_code icode;
- if (e.type_suffix (0).float_p)
+ if (e.type_suffix (m_suffix_index).float_p)
{
/* Put the operands in the normal (fma ...) order, with the accumulator
last. This fits naturally since that's also the unprinted operand
in the asm output. */
e.rotate_inputs_left (0, e.pred != PRED_none ? 5 : 4);
- icode = code_for_aarch64_lane (unspec, e.vector_mode (0));
+ icode = code_for_aarch64_lane (unspec, e.vector_mode (m_suffix_index));
}
else
- icode = INT_CODE (unspec, e.vector_mode (0));
+ icode = INT_CODE (unspec, e.vector_mode (m_suffix_index));
return e.use_exact_insn (icode);
}
};
--
2.25.1
next prev parent reply other threads:[~2023-11-17 17:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 17:23 [PATCH 00/21] aarch64: Add support for SME Richard Sandiford
2023-11-17 17:24 ` [PATCH 01/21] aarch64: Generalise require_immediate_lane_index Richard Sandiford
2023-11-17 17:24 ` [PATCH 02/21] aarch64: Add a result_mode helper function Richard Sandiford
2023-11-17 17:24 ` [PATCH 03/21] aarch64: Use SVE's RDVL instruction Richard Sandiford
2023-11-17 17:24 ` [PATCH 04/21] aarch64: Make AARCH64_FL_SVE requirements explicit Richard Sandiford
2023-11-17 17:25 ` [PATCH 05/21] aarch64: Add group suffixes to SVE intrinsics Richard Sandiford
2023-11-17 17:25 ` [PATCH 06/21] aarch64: Add tuple forms of svreinterpret Richard Sandiford
2023-11-17 17:25 ` [PATCH 07/21] aarch64: Add arm_streaming(_compatible) attributes Richard Sandiford
2023-11-17 17:25 ` [PATCH 08/21] aarch64: Add +sme Richard Sandiford
2023-11-17 17:25 ` [PATCH 09/21] aarch64: Distinguish streaming-compatible AdvSIMD insns Richard Sandiford
2023-11-17 17:26 ` [PATCH 10/21] aarch64: Mark relevant SVE instructions as non-streaming Richard Sandiford
2023-11-17 17:26 ` [PATCH 11/21] aarch64: Switch PSTATE.SM around calls Richard Sandiford
2023-11-17 17:26 ` [PATCH 12/21] aarch64: Add support for SME ZA attributes Richard Sandiford
2023-11-17 17:26 ` [PATCH 13/21] aarch64: Add a register class for w12-w15 Richard Sandiford
2023-11-17 17:27 ` [PATCH 14/21] aarch64: Add a VNx1TI mode Richard Sandiford
2023-11-17 17:27 ` Richard Sandiford [this message]
2023-11-17 17:27 ` [PATCH 16/21] aarch64: Generalise _m rules for SVE intrinsics Richard Sandiford
2023-11-17 17:29 ` [PATCH 17/21] aarch64: Add support for <arm_sme.h> Richard Sandiford
2023-11-17 17:30 ` [PATCH 18/21] aarch64: Add support for __arm_locally_streaming Richard Sandiford
2023-11-17 17:30 ` [PATCH 19/21] aarch64: Handle PSTATE.SM across abnormal edges Richard Sandiford
2023-11-17 17:30 ` [PATCH 20/21] aarch64: Enforce inlining restrictions for SME Richard Sandiford
2023-11-17 17:30 ` [PATCH 21/21] aarch64: Update sibcall handling " Richard Sandiford
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=mptbkbss32b.fsf@arm.com \
--to=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).