Re: [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape

[Christophe Lyon <christophe.lyon@arm.com>]

On 5/11/23 10:30, Richard Sandiford wrote:
> Christophe Lyon <christophe.lyon@arm.com> writes:
>> On 5/10/23 16:52, Kyrylo Tkachov wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Christophe Lyon <christophe.lyon@arm.com>
>>>> Sent: Wednesday, May 10, 2023 2:31 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 15/20] arm: [MVE intrinsics] add unary_acc shape
>>>>
>>>> This patch adds the unary_acc shape description.
>>>>
>>>> 2022-10-25  Christophe Lyon  <christophe.lyon@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