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". Thanks, Richard