Christophe Lyon <christophe.l...@arm.com> writes: > 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?
No. All we can/should do is to resolve the typeless builtin to a fully-typed builtin, based on the argument types. The return type of that fully-typed builtin determines the type of the function call expression (the CALL_EXPR). It's then up to the frontend to do semantic/type checking of the resolved expression type. In other words, information only flows in one direction: argument types -> function overloading -> function return type Thanks, Richard