From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 78B2B385702F for ; Thu, 11 May 2023 10:58:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78B2B385702F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9A9251063; Thu, 11 May 2023 03:58:55 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 638373F5A1; Thu, 11 May 2023 03:58:10 -0700 (PDT) From: Richard Sandiford To: Christophe Lyon Mail-Followup-To: Christophe Lyon ,Kyrylo Tkachov , "gcc-patches\@gcc.gnu.org" , Richard Earnshaw , richard.sandiford@arm.com Cc: Kyrylo Tkachov , "gcc-patches\@gcc.gnu.org" , Richard Earnshaw Subject: Re: [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape References: <20230510133036.596530-1-christophe.lyon@arm.com> <20230510133036.596530-15-christophe.lyon@arm.com> Date: Thu, 11 May 2023 11:58:09 +0100 In-Reply-To: (Christophe Lyon's message of "Thu, 11 May 2023 11:54:48 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-29.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Christophe Lyon writes: > On 5/11/23 10:30, Richard Sandiford wrote: >> Christophe Lyon writes: >>> On 5/10/23 16:52, Kyrylo Tkachov wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christophe Lyon >>>>> Sent: Wednesday, May 10, 2023 2:31 PM >>>>> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; >>>>> Richard Earnshaw ; Richard Sandiford >>>>> >>>>> Cc: Christophe Lyon >>>>> Subject: [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape >>>>> >>>>> This patch adds the unary_acc shape description. >>>>> >>>>> 2022-10-25 Christophe Lyon >>>>> >>>>> 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) >>>>> >>>>> +/* _t vfoo[_](_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 &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