On 5/11/23 10:30, Richard Sandiford wrote:
Christophe Lyon <christophe.l...@arm.com> writes:
On 5/10/23 16:52, Kyrylo Tkachov wrote:
-----Original Message-----
From: Christophe Lyon <christophe.l...@arm.com>
Sent: Wednesday, May 10, 2023 2:31 PM
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov <kyrylo.tkac...@arm.com>;
Richard Earnshaw <richard.earns...@arm.com>; Richard Sandiford
<richard.sandif...@arm.com>
Cc: Christophe Lyon <christophe.l...@arm.com>
Subject: [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape
This patch adds the unary_acc shape description.
2022-10-25 Christophe Lyon <christophe.l...@arm.com>
gcc/
* config/arm/arm-mve-builtins-shapes.cc (unary_acc): New.
* config/arm/arm-mve-builtins-shapes.h (unary_acc): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 28 +++++++++++++++++++++++
gcc/config/arm/arm-mve-builtins-shapes.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/gcc/config/arm/arm-mve-builtins-shapes.cc b/gcc/config/arm/arm-
mve-builtins-shapes.cc
index bff1c3e843b..e77a0cc20ac 100644
--- a/gcc/config/arm/arm-mve-builtins-shapes.cc
+++ b/gcc/config/arm/arm-mve-builtins-shapes.cc
@@ -1066,6 +1066,34 @@ struct unary_def : public overloaded_base<0>
};
SHAPE (unary)
+/* <S0:twice>_t vfoo[_<t0>](<T0>_t)
+
+ i.e. a version of "unary" in which the source elements are half the
+ size of the destination scalar, but have the same type class.
+
+ Example: vaddlvq.
+ int64_t [__arm_]vaddlvq[_s32](int32x4_t a)
+ int64_t [__arm_]vaddlvq_p[_s32](int32x4_t a, mve_pred16_t p) */
+struct unary_acc_def : public overloaded_base<0>
+{
+ void
+ build (function_builder &b, const function_group_info &group,
+ bool preserve_user_namespace) const override
+ {
+ b.add_overloaded_functions (group, MODE_none,
preserve_user_namespace);
+ build_all (b, "sw0,v0", group, MODE_none, preserve_user_namespace);
+ }
+
+ tree
+ resolve (function_resolver &r) const override
+ {
+ /* FIXME: check that the return value is actually
+ twice as wide as arg 0. */
Any reason why we can't add that check now?
I'd rather not add new FIXMEs here...
I understand :-)
That's because the resolver only knows about the arguments, not the
return value:
/* The arguments to the overloaded function. */
vec<tree, va_gc> &m_arglist;
I kept this like what already exists for AArch64/SVE, but we'll need to
extend it to handle return values too, so that we can support all
overloaded forms of vuninitialized
(see https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616003.html)
I meant this extension to be a follow-up work when most intrinsics have
been converted and the few remaining ones (eg. vuninitialized) needs an
improved framework. And that would enable to fix the FIXME.
We can't resolve based on the return type though. It has to be
arguments only. E.g.:
decltype(foo(a, b))
has to be well-defined, even though decltype (by design) provides no
context about "what the caller wants".
So in fact we can probably get rid of (most of) the remaining
definitions of vuninitializedq in arm_mve.h, but not by looking at the
return type (re-reading this I'm wondering whether I overlooked this
when I started the series....)
But for things like vaddlvq, we can't check that the result is actually
written in a twice-as-large as the argument location?
Thanks,
Christophe
Thanks,
Richard
