public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r12-5998] aarch64: Don't classify vector pairs as short vectors [PR103094]
Date: Wed, 15 Dec 2021 12:19:09 +0000 (GMT)	[thread overview]
Message-ID: <20211215121909.E74E23858D28@sourceware.org> (raw)

https://gcc.gnu.org/g:73c3dacef9a30d7d66918606a97c496c71289f1b

commit r12-5998-g73c3dacef9a30d7d66918606a97c496c71289f1b
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Dec 15 12:19:00 2021 +0000

    aarch64: Don't classify vector pairs as short vectors [PR103094]
    
    In this PR we were wrongly classifying a pair of 8-byte vectors
    as a 16-byte “short vector” (in the AAPCS64 sense).  As the
    comment in the patch says, this stems from an old condition
    in aarch64_short_vector_p that is too loose, but that would
    be difficult to tighten now.
    
    We can still do the right thing for the newly-added modes though,
    since there are no backwards compatibility concerns there.
    
    Co-authored-by: Tamar Christina <tamar.christina@arm.com>
    
    gcc/
            PR target/103094
            * config/aarch64/aarch64.c (aarch64_short_vector_p): Return false
            for structure modes, rather than ignoring the type in that case.
    
    gcc/testsuite/
            PR target/103094
            * gcc.target/aarch64/pr103094.c: New test.

Diff:
---
 gcc/config/aarch64/aarch64.c                | 19 +++++++++++++++++--
 gcc/testsuite/gcc.target/aarch64/pr103094.c | 22 ++++++++++++++++++++++
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index f07330cff4f..ff4a808629b 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -19299,7 +19299,21 @@ aarch64_short_vector_p (const_tree type,
   else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT
 	   || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
     {
-      /* Rely only on the type, not the mode, when processing SVE types.  */
+      /* The containing "else if" is too loose: it means that we look at TYPE
+	 if the type is a vector type (good), but that we otherwise ignore TYPE
+	 and look only at the mode.  This is wrong because the type describes
+	 the language-level information whereas the mode is purely an internal
+	 GCC concept.  We can therefore reach here for types that are not
+	 vectors in the AAPCS64 sense.
+
+	 We can't "fix" that for the traditional Advanced SIMD vector modes
+	 without breaking backwards compatibility.  However, there's no such
+	 baggage for the structure modes, which were introduced in GCC 12.  */
+      if (aarch64_advsimd_struct_mode_p (mode))
+	return false;
+
+      /* For similar reasons, rely only on the type, not the mode, when
+	 processing SVE types.  */
       if (type && aarch64_some_values_include_pst_objects_p (type))
 	/* Leave later code to report an error if SVE is disabled.  */
 	gcc_assert (!TARGET_SVE || aarch64_sve_mode_p (mode));
@@ -19310,7 +19324,8 @@ aarch64_short_vector_p (const_tree type,
     {
       /* 64-bit and 128-bit vectors should only acquire an SVE mode if
 	 they are being treated as scalable AAPCS64 types.  */
-      gcc_assert (!aarch64_sve_mode_p (mode));
+      gcc_assert (!aarch64_sve_mode_p (mode)
+		  && !aarch64_advsimd_struct_mode_p (mode));
       return true;
     }
   return false;
diff --git a/gcc/testsuite/gcc.target/aarch64/pr103094.c b/gcc/testsuite/gcc.target/aarch64/pr103094.c
new file mode 100644
index 00000000000..beda99dc1f6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr103094.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fdump-rtl-expand -w" } */
+
+#include <arm_neon.h>
+
+void foo (uint8x8x2_t cols_01_23, uint8x8x2_t cols_45_67, uint16_t*
+outptr0) {
+  uint16x4x4_t cols_01_23_45_67 = { {
+    vreinterpret_u16_u8(cols_01_23.val[0]),
+    vreinterpret_u16_u8(cols_01_23.val[1]),
+    vreinterpret_u16_u8(cols_45_67.val[0]),
+    vreinterpret_u16_u8(cols_45_67.val[1])
+  } };
+
+  vst4_lane_u16(outptr0, cols_01_23_45_67, 0); }
+
+/* Check that we expand to v0 and v2 from the function arguments.  */
+/* { dg-final { scan-rtl-dump {\(reg:V2x8QI \d+ v0 \[ cols_01_23
+\]\)} expand } } */
+/* { dg-final { scan-rtl-dump {\(reg:V2x8QI \d+ v2 \[ cols_45_67
+\]\)} expand } } */
+


                 reply	other threads:[~2021-12-15 12:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20211215121909.E74E23858D28@sourceware.org \
    --to=rsandifo@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).