[PATCH] Allow % to work on vectors

[Andrew Pinski]

Woops forgot the patch.

On Fri, Apr 17, 2009 at 11:48 AM, Andrew Pinski
<Andrew_Pinski@playstation.sony.com> wrote:
> Hi,
>  This patch allows for % (remainder) to work on integer vectors.
> This does not add any patterns that optimize % to just division with a
> subtraction of vector types though, that will be for a seperate patch.
>
> OK? Bootstrapped and tested on i686-linux-gnu with no regressions.
>
> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * c-typeck.c (build_binary_op): Allow % on integal vectors.
> * doc/extend.texi (Vector Extension): Document that % is allowed too.
>
> cp/ChangeLog:
> * typeck.c (build_binary_op): Allow % on integal vectors.
>
> testsuite/ChangeLog:
> * gcc.dg/vector-4.c: New testcase.
> * gcc.dg/simd-1b.c: % is now allowed for integer vectors.
> * g++.dg/ext/vector16.C: New testcase.
>
-------------- next part --------------
Index: doc/extend.texi
===================================================================
--- doc/extend.texi	(revision 146137)
+++ doc/extend.texi	(working copy)
@@ -5741,7 +5741,7 @@ produce code that uses 4 @code{SIs}.
 
 The types defined in this manner can be used with a subset of normal C
 operations.  Currently, GCC will allow using the following operators
-on these types: @code{+, -, *, /, unary minus, ^, |, &, ~}@.
+on these types: @code{+, -, *, /, unary minus, ^, |, &, ~, %}@.
 
 The operations behave like C++ @code{valarrays}.  Addition is defined as
 the addition of the corresponding elements of the operands.  For
Index: testsuite/gcc.dg/vector-4.c
===================================================================
--- testsuite/gcc.dg/vector-4.c	(revision 0)
+++ testsuite/gcc.dg/vector-4.c	(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+#define vector __attribute__((vector_size(4*sizeof(int)) ))
+
+vector int a, b, c;
+
+
+/* Test that remainder works for vectors. */
+void f(void)
+{
+  a = b % c;
+}
Index: testsuite/gcc.dg/simd-1b.c
===================================================================
--- testsuite/gcc.dg/simd-1b.c	(revision 146137)
+++ testsuite/gcc.dg/simd-1b.c	(working copy)
@@ -14,7 +14,7 @@ void
 hanneke ()
 {
   /* Operators on compatible SIMD types.  */
-  a %= b; /* { dg-error "invalid operands to binary %" } */
+  a %= b;
   c &= d;
   a |= b;
   c ^= d;
Index: testsuite/g++.dg/ext/vector16.C
===================================================================
--- testsuite/g++.dg/ext/vector16.C	(revision 0)
+++ testsuite/g++.dg/ext/vector16.C	(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+#define vector __attribute__((vector_size(4*sizeof(int)) ))
+
+vector int a, b, c;
+
+
+/* Test that remainder works for vectors. */
+void f(void)
+{
+  a = b % c;
+}
Index: cp/typeck.c
===================================================================
--- cp/typeck.c	(revision 146137)
+++ cp/typeck.c	(working copy)
@@ -3469,7 +3469,11 @@ cp_build_binary_op (location_t location,
     case FLOOR_MOD_EXPR:
       warn_for_div_by_zero (location, op1);
 
-      if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
+      if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE
+	  && TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+	  && TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE)
+	common = 1;
+      else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
 	{
 	  /* Although it would be tempting to shorten always here, that loses
 	     on some targets, since the modulo instruction is undefined if the
Index: c-typeck.c
===================================================================
--- c-typeck.c	(revision 146137)
+++ c-typeck.c	(working copy)
@@ -8768,7 +8768,11 @@ build_binary_op (location_t location, en
     case FLOOR_MOD_EXPR:
       warn_for_div_by_zero (location, op1);
 
-      if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
+      if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE
+	  && TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+	  && TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE)
+	common = 1;
+      else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
 	{
 	  /* Although it would be tempting to shorten always here, that loses
 	     on some targets, since the modulo instruction is undefined if the