From: Richard Sandiford <richard.sandiford@arm.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] vect: Tighten check for SLP memory groups [PR103517]
Date: Wed, 01 Dec 2021 10:45:48 +0000 [thread overview]
Message-ID: <mpt35ncy55v.fsf@arm.com> (raw)
When checking for compatible stmts, vect_build_slp_tree_1 did:
&& !(STMT_VINFO_GROUPED_ACCESS (stmt_info)
&& (first_stmt_code == ARRAY_REF
|| first_stmt_code == BIT_FIELD_REF
|| first_stmt_code == INDIRECT_REF
|| first_stmt_code == COMPONENT_REF
|| first_stmt_code == MEM_REF)))
That is, it allowed any rhs_code as long as the first_stmt_code
looked valid. This had the effect of allowing IFN_MASK_LOAD
to be paired with an earlier non-call code (but didn't allow
the reverse).
This patch makes the check symmetrical.
Still testing on x86_64-linux-gnu. OK if testing passes, or doesn't
this seem like the right approach?
Richard
gcc/
PR tree-optimization/103517
* tree-vect-slp.c (vect_build_slp_tree_1): When allowing two
different component references, check the codes of both them,
rather than just the first.
gcc/testsuite/
PR tree-optimization/103517
* gcc.dg/vect/pr103517.c: New test.
---
gcc/testsuite/gcc.dg/vect/pr103517.c | 13 +++++++++++++
gcc/tree-vect-slp.c | 7 ++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr103517.c
diff --git a/gcc/testsuite/gcc.dg/vect/pr103517.c b/gcc/testsuite/gcc.dg/vect/pr103517.c
new file mode 100644
index 00000000000..de87fc48f84
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr103517.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=skylake-avx512" { target x86_64-*-* i?86-*-* } } */
+
+int a;
+short b, c;
+extern short d[];
+void e() {
+ for (short f = 1; f < (short)a; f += 2)
+ if (d[f + 1]) {
+ b = d[f];
+ c = d[f + 1];
+ }
+}
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 7bff5118bd0..bc22ffeed82 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1121,7 +1121,12 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char *swap,
|| first_stmt_code == BIT_FIELD_REF
|| first_stmt_code == INDIRECT_REF
|| first_stmt_code == COMPONENT_REF
- || first_stmt_code == MEM_REF)))
+ || first_stmt_code == MEM_REF)
+ && (rhs_code == ARRAY_REF
+ || rhs_code == BIT_FIELD_REF
+ || rhs_code == INDIRECT_REF
+ || rhs_code == COMPONENT_REF
+ || rhs_code == MEM_REF)))
|| first_stmt_load_p != load_p
|| first_stmt_phi_p != phi_p)
{
--
2.25.1
next reply other threads:[~2021-12-01 10:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 10:45 Richard Sandiford [this message]
2021-12-01 13:14 ` Richard Biener
2021-12-01 13:25 ` Richard Sandiford
2021-12-01 13:28 ` Richard Biener
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=mpt35ncy55v.fsf@arm.com \
--to=richard.sandiford@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).