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 Sandiford <Richard.Sandiford@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Richard Biener <rguenther@suse.de>
Subject: RE: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]
Date: Thu, 26 Jan 2023 15:06:53 +0000	[thread overview]
Message-ID: <PAXPR08MB692609F668931DE1C568A52693CF9@PAXPR08MB6926.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <22ba05fb-774e-62b8-64a2-90c5d73fcaba@arm.com>

Hi Andre,

> -----Original Message-----
> From: Andre Vieira (lists) <andre.simoesdiasvieira@arm.com>
> Sent: Tuesday, January 24, 2023 1:54 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford <Richard.Sandiford@arm.com>; Richard Earnshaw
> <Richard.Earnshaw@arm.com>; Richard Biener <rguenther@suse.de>;
> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
> Subject: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE
> predicates before use [PR 107674]
> 
> Hi,
> 
> This patch teaches GCC that zero-extending a MVE predicate from 16-bits
> to 32-bits and then only using 16-bits is a no-op.
> It does so in two steps:
> - it lets gcc know that it can access any MVE predicate mode using any
> other MVE predicate mode without needing to copy it, using the
> TARGET_MODES_TIEABLE_P hook,
> - it teaches simplify_subreg to optimize a subreg with a vector
> outermode, by replacing this outermode with a same-sized integer mode
> and trying the avalailable optimizations, then if successful it
> surrounds the result with a subreg casting it back to the original
> vector outermode.
> 
> This removes the unnecessary zero-extending shown on PR 107674 (though
> it's a sign-extend there), that was introduced in gcc 11.
> 
> Bootstrapped on aarch64-none-linux-gnu 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
>          * conig/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
>          (arm_modes_tieable_p): Make MVE predicate modes tieable.
> 	* config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
> 	* simplify-rtx.cc (simplify_context::simplify_subreg): Teach
> 	simplify_subreg to simplify subregs where the outermode is not
> scalar.

The arm changes look ok to me. We'll want a midend maintainer to have a look at simplify-rtx.cc

> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
> 	zero-extend.

diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
index 26a565b79dd1348e361b3aa23a1d6e6d13bffce8..8e562a9f065eff157f63ebd5acf9af0a2155b5c5 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
@@ -16,9 +16,6 @@ void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
 **	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

Ah I see, that's the testcase from patch 1/3 that I criticized :)
Maybe if we just scan for absence of an uxth, vmrs and vmsr it will be more robust?
Thanks,
Kyrill

  reply	other threads:[~2023-01-26 15:07 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
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 [this message]
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=PAXPR08MB692609F668931DE1C568A52693CF9@PAXPR08MB6926.eurprd08.prod.outlook.com \
    --to=kyrylo.tkachov@arm.com \
    --cc=Andre.SimoesDiasVieira@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).