From: Richard Sandiford <richard.sandiford@arm.com>
To: Christophe Lyon <christophe.lyon@arm.com>
Cc: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>,
"gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape
Date: Thu, 11 May 2023 11:58:09 +0100 [thread overview]
Message-ID: <mptfs83gmny.fsf@arm.com> (raw)
In-Reply-To: <de5992f2-cfdd-390f-c765-28b848ea112b@arm.com> (Christophe Lyon's message of "Thu, 11 May 2023 11:54:48 +0200")
Christophe Lyon <christophe.lyon@arm.com> writes:
> 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?
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
next prev parent reply other threads:[~2023-05-11 10:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 13:30 [PATCH 01/20] arm: [MVE intrinsics] factorize vcmp Christophe Lyon
2023-05-10 13:30 ` [PATCH 02/20] arm: [MVE intrinsics] add cmp shape Christophe Lyon
2023-05-10 13:30 ` [PATCH 03/20] arm: [MVE intrinsics] rework vcmp Christophe Lyon
2023-05-10 13:30 ` [PATCH 04/20] arm: [MVE intrinsics] factorize vrev16q vrev32q vrev64q Christophe Lyon
2023-05-10 13:30 ` [PATCH 05/20] arm: [MVE intrinsics] rework " Christophe Lyon
2023-05-10 13:30 ` [PATCH 06/20] arm: [MVE intrinsics] factorize vdupq Christophe Lyon
2023-05-10 13:30 ` [PATCH 07/20] arm: [MVE intrinsics] add unary_n shape Christophe Lyon
2023-05-10 13:30 ` [PATCH 08/20] arm: [MVE intrinsics] rework vdupq Christophe Lyon
2023-05-10 13:30 ` [PATCH 09/20] arm: [MVE intrinsics] factorize vaddvq Christophe Lyon
2023-05-10 13:30 ` [PATCH 10/20] arm: [MVE intrinsics] add unary_int32 shape Christophe Lyon
2023-05-10 13:30 ` [PATCH 11/20] arm: [MVE intrinsics] rework vaddvq Christophe Lyon
2023-05-10 13:30 ` [PATCH 12/20] arm: [MVE intrinsics] factorize vaddvaq Christophe Lyon
2023-05-10 13:30 ` [PATCH 13/20] arm: [MVE intrinsics] add unary_int32_acc shape Christophe Lyon
2023-05-10 13:30 ` [PATCH 14/20] arm: [MVE intrinsics] rework vaddvaq Christophe Lyon
2023-05-10 13:30 ` [PATCH 15/20] arm: [MVE intrinsics] add unary_acc shape Christophe Lyon
2023-05-10 14:52 ` Kyrylo Tkachov
2023-05-11 8:21 ` Christophe Lyon
2023-05-11 8:23 ` Kyrylo Tkachov
2023-05-11 8:24 ` Christophe Lyon
2023-05-11 8:30 ` Richard Sandiford
2023-05-11 9:54 ` Christophe Lyon
2023-05-11 10:58 ` Richard Sandiford [this message]
2023-05-10 13:30 ` [PATCH 16/20] arm: [MVE intrinsics] factorize vaddlvq Christophe Lyon
2023-05-10 13:30 ` [PATCH 17/20] arm: [MVE intrinsics] rework vaddlvq Christophe Lyon
2023-05-10 13:30 ` [PATCH 18/20] arm: [MVE intrinsics] factorize vmovlbq vmovltq Christophe Lyon
2023-05-10 13:30 ` [PATCH 19/20] arm: [MVE intrinsics] add unary_widen shape Christophe Lyon
2023-05-10 13:30 ` [PATCH 20/20] arm: [MVE intrinsics] rework vmovlbq vmovltq Christophe Lyon
2023-05-10 16:53 ` [PATCH 01/20] arm: [MVE intrinsics] factorize vcmp Kyrylo Tkachov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mptfs83gmny.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=Kyrylo.Tkachov@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=christophe.lyon@arm.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).