public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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
> 


  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).