From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Murray Steele <Murray.Steele@arm.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/2][GCC] arm: Declare MVE types internally via pragma
Date: Thu, 18 Nov 2021 15:45:11 +0000 [thread overview]
Message-ID: <342ef4e3-6013-2d67-adc8-6310febe2f52@foss.arm.com> (raw)
In-Reply-To: <55ba6a8c-4dda-c023-0e93-a052e4830d06@arm.com>
On 16/11/2021 10:15, Murray Steele via Gcc-patches wrote:
> Hi all,
>
> This patch moves the implementation of MVE ACLE types from
> arm_mve_types.h to inside GCC via a new pragma, which replaces the prior
> type definitions. This allows for the types to be used internally for
> intrinsic function definitions.
>
> Bootstrapped and regression tested on arm-none-linux-gnuabihf, and
> regression tested on arm-eabi -- no issues.
>
> Thanks,
> Murray
>
> gcc/ChangeLog:
>
> * config.gcc: Add arm-mve-builtins.o to extra_objs for arm-*-*-*
> targets.
> * config/arm/arm-c.c (arm_pragma_arm): Handle new pragma.
> (arm_register_target_pragmas): Register new pragma.
> * config/arm/arm-protos.h: Add arm_mve namespace and declare
> arm_handle_mve_types_h.
> * config/arm/arm_mve_types.h: Replace MVE type definitions with
> new pragma.
> * config/arm/t-arm: Add arm-mve-builtins.o target.
> * config/arm/arm-mve-builtins.cc: New file.
> * config/arm/arm-mve-builtins.def: New file.
> * config/arm/arm-mve-builtins.h: New file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/mve/mve.exp: Add new subdirectories.
> * gcc.target/arm/mve/general-c/type_redef_1.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_10.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_11.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_12.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_13.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_14.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_15.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_16.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_17.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_18.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_19.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_2.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_20.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_21.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_22.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_23.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_24.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_25.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_26.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_27.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_28.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_29.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_3.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_30.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_31.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_4.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_5.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_6.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_7.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_8.c: New test.
> * gcc.target/arm/mve/general-c/type_redef_9.c: New test.
> * gcc.target/arm/mve/general/double_pragmas_1.c: New test.
> * gcc.target/arm/mve/general/nomve_1.c: New test.
>
>
This is mostly OK, but can't we reduce the number of tests somewhat?
For example, I think you can merge type_redef_13.c and type_redef_14.c
by writing
/* { dg-do compile } */
/* { dg-require-effective-target arm_v8_1m_mve_ok } */
/* { dg-add-options arm_v8_1m_mve } */
int uint8x16x4_t; /* { dg-message "note: previous declaration of
'uint8x16x4_t'" } */
int uint16x8x2_t; /* { dg-message "note: previous declaration of
'uint16x8x2_t'" } */
#pragma GCC arm "arm_mve_types.h" /* { dg-error {'uint8x16x4_t'
redeclared} } */
/* { dg-error {'uint16x8x2_t' redeclared} {target *-*-*} .-1 } */
etc. Note the second dg-error is anchored to the line above it (.-1).
R.
next prev parent reply other threads:[~2021-11-18 15:45 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 [this message]
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
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=342ef4e3-6013-2d67-adc8-6310febe2f52@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).