[PATCH] middle-end/126788 - more vector folding

Richard Biener <[email protected]>
Newsgroups gmane.comp.gcc.patches
Message-ID <[email protected]>
The last match.pd update for double-conversion folding didn't handle
the case where a vector conversion would go away because
supportable_convert_operation doesn't consider a noop conversion
(or a sign conversion).  The following rectifies this, allowing
a NOP_EXPR and VIEW_CONVERT_EXPR for same mode types as supportable
conversion as we can RTL expand that just fine.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

I'll note that the .VEC_CONVERT IFNs from initial __builtin_convertvector
lowering survive unfolded until the veclower pass where, if the 
conversions are not supported, they will be open-coded and not
folded either.  I wonder why we chose to expand to .VEC_CONVERT
instead of using FLOAT_EXPR/FIX_TRUNC_EXPR/NOP_EXPR as appropriate
and lower those if not supported?  At least I don't look forward to
add .VEC_CONVERT support to all conversion foldings?

I'll also note that the guards I put in place when adding
vector integer support to double-conversion folding will now
pessimize the case where neither (one of?) the former nor the
new conversion would be supported because of the type not
having vector mode.

	PR middle-end/126788
	* optabs-tree.cc (supportable_convert_operation): For same
	modes allow NOP_EXPR and VIEW_CONVERT_EXPR.

	* gcc.target/i386/pr126788.c: New testcase.
---
 gcc/optabs-tree.cc                       |  4 ++++
 gcc/testsuite/gcc.target/i386/pr126788.c | 24 ++++++++++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr126788.c

diff --git a/gcc/optabs-tree.cc b/gcc/optabs-tree.cc
index 5fbdcd3a730..5360a509f8d 100644
--- a/gcc/optabs-tree.cc
+++ b/gcc/optabs-tree.cc
@@ -375,6 +375,10 @@ supportable_convert_operation (enum tree_code code,
   if (!VECTOR_MODE_P (m1) || !VECTOR_MODE_P (m2))
     return false;
 
+  if (m1 == m2
+      && (CONVERT_EXPR_CODE_P (code) || code == VIEW_CONVERT_EXPR))
+    return true;
+
   /* First check if we can done conversion directly.  */
   if ((code == FIX_TRUNC_EXPR
        && can_fix_p (m1,m2,TYPE_UNSIGNED (vectype_out), &truncp)
diff --git a/gcc/testsuite/gcc.target/i386/pr126788.c b/gcc/testsuite/gcc.target/i386/pr126788.c
new file mode 100644
index 00000000000..0448284e8f6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr126788.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O -msse2" } */
+
+typedef int  v2si __attribute__((vector_size (8)));
+typedef unsigned int  v2usi __attribute__((vector_size (8)));
+typedef long long v2di __attribute__((vector_size (16)));
+
+v2si
+f1 (v2si a, v2si b)
+{
+
+  v2di z = __builtin_convertvector (a, v2di);
+  return __builtin_convertvector (z, v2si);
+}
+
+v2usi
+f2 (v2si a, v2si b)
+{
+
+  v2di z = __builtin_convertvector (a, v2di);
+  return __builtin_convertvector (z, v2usi);
+}
+
+/* { dg-final { scan-assembler-not "xmm" { target { ! ia32 } } } } */
-- 
2.51.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.