public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
To: Andre Simoes Dias Vieira <Andre.SimoesDiasVieira@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: RE: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]
Date: Thu, 26 Jan 2023 15:03:07 +0000	[thread overview]
Message-ID: <PAXPR08MB692656F943E7A2DC4728AF2C93CF9@PAXPR08MB6926.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <PAXPR08MB692666B6809E4C4048D09FF793CF9@PAXPR08MB6926.eurprd08.prod.outlook.com>



> -----Original Message-----
> From: Kyrylo Tkachov
> Sent: Thursday, January 26, 2023 3:02 PM
> To: Andre Vieira (lists) <andre.simoesdiasvieira@arm.com>; gcc-
> patches@gcc.gnu.org
> Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>
> Subject: RE: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
> 107674]
> 
> Hi Andre,
> 
> > -----Original Message-----
> > From: Andre Vieira (lists) <andre.simoesdiasvieira@arm.com>
> > Sent: Tuesday, January 24, 2023 1:41 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>; Richard Earnshaw
> > <Richard.Earnshaw@arm.com>
> > Subject: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
> > 107674]
> >
> > Hi,
> >
> > The ACLE defines mve_pred16_t as an unsigned short.  This patch makes
> > sure GCC treats the predicate as an unsigned type, rather than signed.
> >
> > Bootstrapped on aarch64-none-eabi and regression tested on arm-none-
> eabi
> > and armeb-none-eabi for armv8.1-m.main+mve.fp.
> >
> > OK for trunk?
> >
> > gcc/ChangeLog:
> >
> > 	PR target/107674
> > 	* config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to
> > use
> > 	new qualifiers parameter and use unsigned short type for MVE
> > predicate.
> > 	(arm_init_builtin): Call arm_simd_builtin_type with qualifiers
> > 	parameter.
> > 	(arm_init_crypto_builtins): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 	PR target/107674
> > 	* gcc.target/arm/mve/mve_vpt.c: New test.
> 
> diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
> index
> 11d7478d9df69139802a9d42c09dd0de7480b60e..6c67cec93ff76a4b42f3a0b3
> 05f697142e88fcd9 100644
> --- a/gcc/config/arm/arm-builtins.cc
> +++ b/gcc/config/arm/arm-builtins.cc
> @@ -1489,12 +1489,14 @@ arm_lookup_simd_builtin_type (machine_mode
> mode,
>  }
> 
>  static tree
> -arm_simd_builtin_type (machine_mode mode, bool unsigned_p, bool
> poly_p)
> +arm_simd_builtin_type (machine_mode mode, enum arm_type_qualifiers
> qualifiers)
>  {
> 
> I think in C++ now we can leave out the "enum" here.
> 
> diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> new file mode 100644
> index
> 0000000000000000000000000000000000000000..26a565b79dd1348e361b3a
> a23a1d6e6d13bffce8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> @@ -0,0 +1,27 @@
> +/* { dg-options "-O2" } */
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +#include <arm_mve.h>
> +void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
> +{
> +    uint8x16_t va = vldrbq_u8 (a);
> +    uint8x16_t vb = vldrbq_u8 (b);
> +    mve_pred16_t p = vcmpeqq_u8 (va, vb);
> +    uint8x16_t vc = vaddq_x_u8 (va, vb, p);
> +    vstrbq_p_u8 (c, vc, p);
> +}
> +/*
> +** test0:
> +**	vldrb.8	q2, \[r0\]
> +**	vldrb.8	q1, \[r1\]
> +**	vcmp.i8	eq, q2, q1
> +**	vmrs	r3, p0	@ movhi
> +**	uxth	r3, r3
> +**	vmsr	p0, r3	@ movhi
> +**	vpst
> +**	vaddt.i8	q3, q2, q1
> +**	vpst
> +**	vstrbt.8	q3, \[r2\]
> +**	bx	lr
> +*/
> 
> This explicit assembly matching looks quite fragile and sensitive to future
> scheduling and RA changes.
> Is there something more targeted we could scan for to check that the
> predicate is unsigned now?

The patch looks fine to me btw. With a more robust testcase and the cosmetic fix above it can go in.
Thanks,
Kyrill

> 
> Thanks,
> Kyrill

  reply	other threads:[~2023-01-26 15:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 13:31 [PATCH 0/3] arm: Fix regressions around MVE predicate codegen Andre Vieira (lists)
2023-01-24 13:40 ` [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674] Andre Vieira (lists)
2023-01-24 13:48   ` Andre Vieira (lists)
2023-01-26 15:02   ` Kyrylo Tkachov
2023-01-26 15:03     ` Kyrylo Tkachov [this message]
2023-01-27  9:54     ` Andre Vieira (lists)
2023-01-27  9:56       ` Kyrylo Tkachov
2023-01-30 16:38         ` Andre Vieira (lists)
2023-01-30 16:40           ` Kyrylo Tkachov
2023-01-24 13:54 ` [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use " Andre Vieira (lists)
2023-01-26 15:06   ` Kyrylo Tkachov
2023-01-27  9:58     ` Andre Vieira (lists)
2023-01-27  9:59       ` Kyrylo Tkachov
2023-01-30 16:41         ` Andre Vieira (lists)
2023-01-30 23:17   ` Richard Sandiford
2023-01-31  6:15     ` Richard Sandiford
2023-01-24 13:56 ` [PATCH 3/3] arm: Fix MVE predicates synthesis [PR 108443] Andre Vieira (lists)
2023-01-25 17:40   ` Andre Vieira (lists)
2023-01-31  9:53     ` Kyrylo Tkachov
2023-01-31 11:38       ` Andre Vieira (lists)
2023-01-31 16:44     ` 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=PAXPR08MB692656F943E7A2DC4728AF2C93CF9@PAXPR08MB6926.eurprd08.prod.outlook.com \
    --to=kyrylo.tkachov@arm.com \
    --cc=Andre.SimoesDiasVieira@arm.com \
    --cc=Richard.Earnshaw@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).