public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Michael Meissner <meissner@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/users/meissner/heads/work084)] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.
Date: Tue, 29 Mar 2022 23:54:17 +0000 (GMT)	[thread overview]
Message-ID: <20220329235417.D92403858C54@sourceware.org> (raw)

https://gcc.gnu.org/g:d373f6abef57da688ded957f456d767b923382e0

commit d373f6abef57da688ded957f456d767b923382e0
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Tue Mar 29 19:53:57 2022 -0400

    Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.
    
    This is version 2 of the patch.  The original patch was:
    
    | Date: Mon, 28 Mar 2022 12:26:02 -0400
    | Subject: [PATCH 1/4] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.
    | Message-ID: <YkHhmvwSJF7DUDhJ@toto.the-meissners.org>
    | https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592420.html
    
    In PR target/99293, it was pointed out that doing:
    
            vector long long dest0, dest1, src;
            /* ... */
            dest0 = vec_splats (vec_extract (src, 0));
            dest1 = vec_splats (vec_extract (src, 1));
    
    would generate slower code.
    
    It generates the following code on power8:
    
            ;; vec_splats (vec_extract (src, 0))
            xxpermdi 0,34,34,3
            xxpermdi 34,0,0,0
    
            ;; vec_splats (vec_extract (src, 1))
            xxlor 0,34,34
            xxpermdi 34,0,0,0
    
    However on power9 and power10 it generates:
    
            ;; vec_splats (vec_extract (src, 0))
            mfvsld 3,34
            mtvsrdd 34,9,9
    
            ;; vec_splats (vec_extract (src, 1))
            mfvsrd 9,34
            mtvsrdd 34,9,9
    
    This is due to the power9 having the mfvsrld instruction which can extract
    either 64-bit element into a GPR.  While there are alternatives for both
    vector registers and GPR registers, the register allocator prefers to put
    DImode into GPR registers.
    
    However in this case, it is better to have a single combiner pattern that
    can generate a single xxpermdi, instead of doing 2 insnsns (the extract
    and then the concat).  This is particularly true if the two operations are
    move from vector register and move to vector register.  As Segher pointed
    out in a previous version of the patch, the combiner already tries doing
    creating a (vec_duplicate (vec_select ...)) pattern, but we didn't provide
    one.
    
    This patch reworks vsx_xxspltd_<mode> for V2DImode and V2DFmode so that it
    no longer uses an UNSPEC.  Instead it uses VEC_DUPLICATE, which the
    combiner checks for.
    
    I have built Spec 2017 with this patch installed, and the cam4_r benchmark
    is the only benchmark that generated different code (3 mfvsrld/mtvsrdd
    pairs of instructions were replaced with xxpermdi).
    
    I have built bootstrap versions on the following systems and I have run
    the regression tests.  There were no regressions in the runs:
    
            Power9 little endian, --with-cpu=power9
            Power10 little endian, --with-cpu=power10
            Power8 big endian, --with-cpu=power8 (both 32-bit & 64-bit tests)
    
    Can I install this into the trunk?  After a burn-in period, can I backport
    and install this into GCC 11 and GCC 10 branches?
    
    2022-03-29   Michael Meissner  <meissner@linux.ibm.com>
    
    gcc/
            PR target/99293
            * config/rs6000/rs6000-p8swap.cc (rtx_is_swappable_p): Remove
            UNSPEC_VSX_XXSPLTD case.
            * config/rs6000/vsx.md (UNSPEC_VSX_XXSPLTD): Delete.
            (vsx_xxspltd_<mode>): Rewrite to use VEC_DUPLICATE.
    
    gcc/testsuite:
            PR target/99293
            * gcc.target/powerpc/builtins-1.c: Update insn count.
            * gcc.target/powerpc/pr99293.c: New test.

Diff:
---
 gcc/config/rs6000/rs6000-p8swap.cc            |  1 -
 gcc/config/rs6000/vsx.md                      | 19 +++++++-------
 gcc/testsuite/gcc.target/powerpc/builtins-1.c |  2 +-
 gcc/testsuite/gcc.target/powerpc/pr99293.c    | 36 +++++++++++++++++++++++++++
 4 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-p8swap.cc b/gcc/config/rs6000/rs6000-p8swap.cc
index d301bc3fe59..1973d9c8245 100644
--- a/gcc/config/rs6000/rs6000-p8swap.cc
+++ b/gcc/config/rs6000/rs6000-p8swap.cc
@@ -805,7 +805,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
 	  case UNSPEC_VUPKLU_V4SF:
 	    return 0;
 	  case UNSPEC_VSPLT_DIRECT:
-	  case UNSPEC_VSX_XXSPLTD:
 	    *special = SH_SPLAT;
 	    return 1;
 	  case UNSPEC_REDUC_PLUS:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 15bd86dfdfb..82fa4bbbfc4 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -296,7 +296,6 @@
    UNSPEC_VSX_XXPERM
 
    UNSPEC_VSX_XXSPLTW
-   UNSPEC_VSX_XXSPLTD
    UNSPEC_VSX_DIVSD
    UNSPEC_VSX_DIVUD
    UNSPEC_VSX_DIVSQ
@@ -4676,16 +4675,18 @@
 ;; V2DF/V2DI splat for use by vec_splat builtin
 (define_insn "vsx_xxspltd_<mode>"
   [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
-        (unspec:VSX_D [(match_operand:VSX_D 1 "vsx_register_operand" "wa")
-	               (match_operand:QI 2 "u5bit_cint_operand" "i")]
-                      UNSPEC_VSX_XXSPLTD))]
+	(vec_duplicate:VSX_D
+	 (vec_select:<VS_scalar>
+	  (match_operand:VSX_D 1 "gpc_reg_operand" "wa")
+	  (parallel [(match_operand:QI 2 "const_0_to_1_operand" "i")]))))]
   "VECTOR_MEM_VSX_P (<MODE>mode)"
 {
-  if ((BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 0)
-      || (!BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 1))
-    return "xxpermdi %x0,%x1,%x1,0";
-  else
-    return "xxpermdi %x0,%x1,%x1,3";
+  HOST_WIDE_INT dword = INTVAL (operands[2]);
+  if (!BYTES_BIG_ENDIAN)
+    dword = !dword;
+
+  operands[3] = GEN_INT (3*dword);
+  return "xxpermdi %x0,%x1,%x1,%3";
 }
   [(set_attr "type" "vecperm")])
 
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1.c b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
index 28cd1aa6b1a..98783668bce 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
@@ -1035,4 +1035,4 @@ foo156 (vector unsigned short usa)
 /* { dg-final { scan-assembler-times {\mvmrglb\M} 3 } } */
 /* { dg-final { scan-assembler-times {\mvmrgew\M} 4 } } */
 /* { dg-final { scan-assembler-times {\mvsplth|xxsplth\M} 4 } } */
-/* { dg-final { scan-assembler-times {\mxxpermdi\M} 44 } } */
+/* { dg-final { scan-assembler-times {\mxxpermdi\M} 42 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr99293.c b/gcc/testsuite/gcc.target/powerpc/pr99293.c
new file mode 100644
index 00000000000..03c22f8f4de
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr99293.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O2 -mvsx" } */
+
+/* Test for PR 99263, which wants to do:
+   __builtin_vec_splats (__builtin_vec_extract (v, n))
+
+   where v is a V2DF or V2DI vector and n is either 0 or 1.  Previously the
+   compiler would do a direct move to the GPR registers to select the item and
+   a direct move from the GPR registers to do the splat.  */
+
+vector long long
+splat_dup_ll_0 (vector long long v)
+{
+  return __builtin_vec_splats (__builtin_vec_extract (v, 0));
+}
+	
+vector long long
+splat_dup_ll_1 (vector long long v)
+{
+  return __builtin_vec_splats (__builtin_vec_extract (v, 1));
+}
+
+vector double
+splat_dup_d_0 (vector double v)
+{
+  return __builtin_vec_splats (__builtin_vec_extract (v, 0));
+}
+	
+vector double
+splat_dup_d_1 (vector double v)
+{
+  return __builtin_vec_splats (__builtin_vec_extract (v, 1));
+}
+	
+/* { dg-final { scan-assembler-times {\mxxpermdi\M} 4 } } */


             reply	other threads:[~2022-03-29 23:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 23:54 Michael Meissner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-31 14:01 Michael Meissner
2022-03-31 14:00 Michael Meissner
2022-03-31 14:00 Michael Meissner
2022-03-31 14:00 Michael Meissner
2022-03-31 14:00 Michael Meissner
2022-03-30 18:00 Michael Meissner
2022-03-29 23:33 Michael Meissner
2022-03-29  3:05 Michael Meissner
2022-03-29  0:11 Michael Meissner

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=20220329235417.D92403858C54@sourceware.org \
    --to=meissner@gcc.gnu.org \
    --cc=gcc-cvs@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).