From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Murray Steele <Murray.Steele@arm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/2][GCC] arm: Declare MVE types internally via pragma
Date: Wed, 8 Dec 2021 17:34:49 +0000 [thread overview]
Message-ID: <9849efef-a0db-825a-2473-8f71dc2412b6@foss.arm.com> (raw)
In-Reply-To: <b9c4b2d2-7844-ccd1-0136-b49ec2c717c4@arm.com>
On 08/12/2021 15:39, Murray Steele via Gcc-patches wrote:
> Hi,
>
> Thank you for the feedback, I'll make the noted changes to the changelog and
> add the missing end-of-namespace comments.
>
> On 08/12/2021 15:23, Richard Earnshaw wrote:
>
>> diff --git a/gcc/config/arm/arm-mve-builtins.def b/gcc/config/arm/arm-mve-builtins.def
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..02a46bec3e4cba6add9bce4021c732e15aa8b012
>> --- /dev/null
>> +++ b/gcc/config/arm/arm-mve-builtins.def
>> @@ -0,0 +1,41 @@
>>
>> +#ifndef DEF_MVE_TYPE
>> +#define DEF_MVE_TYPE(A, B)
>> +#endif
>>
>> When would this file ever be included when this macro wasn't defined? Better to require the caller to define this by using #error if it's missing.
>>
>> then...
>>
>> +
>> +#undef DEF_MVE_TYPE
>>
>> This isn't needed anymore, because caller should undef it after use.
>
>
> I'd added this because later patches that build from this series will most
> likely need to define further DEF_MVE_* macros, in the style of the current
> SVE implementation. You are right that it is unnecessary for right now though,
> and I'll remove it too.
The best thing to do in that case then is to require the caller to
explicitly define DEF_MVE_TYPE as a NOP when it isn't required. It
means a bit more churn at each call site, but I think it's more robust
longer term as it is clear which operations are going to be extracted.
R.
>
> Thanks again,
>
> Murray
>
next prev parent reply other threads:[~2021-12-08 17:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 10:15 Murray Steele
2021-11-18 15:45 ` Richard Earnshaw
2021-11-23 9:37 ` Murray Steele
2021-11-23 14:16 ` Richard Earnshaw
2021-11-23 15:45 ` Murray Steele
2021-11-25 9:42 ` Murray Steele
2021-12-08 10:04 ` [PING][PATCH " Murray Steele
2021-12-08 15:23 ` [PATCH " Richard Earnshaw
2021-12-08 15:39 ` Murray Steele
2021-12-08 17:34 ` Richard Earnshaw [this message]
2021-12-09 15:24 ` [PATCH v3 " Murray Steele
2021-12-21 11:20 ` Murray Steele
2021-12-22 15:00 ` Richard Earnshaw
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=9849efef-a0db-825a-2473-8f71dc2412b6@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=Murray.Steele@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).