public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Artem Shinkarov <artyom.shinkaroff@gmail.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: New warning for expanded vector operations
Date: Fri, 07 Oct 2011 07:13:00 -0000	[thread overview]
Message-ID: <CABYV9SXXoXQs4ER3nP_JDVWE0KcrJZB6dWw5h3GC=ZaxgGuvLw@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc0OtGVb_gCmh0Qq5wuMAHGDqZjzCdWPDwd0zOFkr6o8xw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6389 bytes --]

On Wed, Oct 5, 2011 at 12:35 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Oct 5, 2011 at 1:28 PM, Artem Shinkarov
> <artyom.shinkaroff@gmail.com> wrote:
>> On Wed, Oct 5, 2011 at 9:40 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
>>> <artyom.shinkaroff@gmail.com> wrote:
>>>> Hi
>>>>
>>>> Here is a patch to inform a programmer about the expanded vector operation.
>>>> Bootstrapped on x86-unknown-linux-gnu.
>>>>
>>>> ChangeLog:
>>>>
>>>>        * gcc/tree-vect-generic.c (expand_vector_piecewise): Adjust to
>>>>          produce the warning.
>>>>          (expand_vector_parallel): Adjust to produce the warning.
>>>
>>> Entries start without gcc/, they are relative to the gcc/ChangeLog file.
>>
>> Sure, sorry.
>>
>>>>          (lower_vec_shuffle): Adjust to produce the warning.
>>>>        * gcc/common.opt: New warning Wvector-operation-expanded.
>>>>        * gcc/doc/invoke.texi: Document the wawning.
>>>>
>>>>
>>>> Ok?
>>>
>>> I don't like the name -Wvector-operation-expanded.  We emit a
>>> similar warning for missed inline expansions with -Winline, so
>>> maybe -Wvector-extensions (that's the name that appears
>>> in the C extension documentation).
>>
>> Hm, I don't care much about the name, unless it gets clear what the
>> warning is used for.  I am not really sure that Wvector-extensions
>> makes it clear.  Also, I don't see anything bad if the warning will
>> pop up during the vectorisation. Any vector operation performed
>> outside the SIMD accelerator looks suspicious, because it actually
>> doesn't improve performance.  Such a warning during the vectorisation
>> could mean that a programmer forgot some flag, or the constant
>> propagation failed to deliver a constant, or something else.
>>
>> Conceptually the text I am producing is not really a warning, it is
>> more like an information, but I am not aware of the mechanisms that
>> would allow me to introduce a flag triggering inform () or something
>> similar.
>>
>> What I think we really need to avoid is including this warning in the
>> standard Ox.
>>
>>> +  location_t loc = gimple_location (gsi_stmt (*gsi));
>>> +
>>> +  warning_at (loc, OPT_Wvector_operation_expanded,
>>> +             "vector operation will be expanded piecewise");
>>>
>>>   v = VEC_alloc(constructor_elt, gc, (nunits + delta - 1) / delta);
>>>   for (i = 0; i < nunits;
>>> @@ -260,6 +264,10 @@ expand_vector_parallel (gimple_stmt_iter
>>>   tree result, compute_type;
>>>   enum machine_mode mode;
>>>   int n_words = tree_low_cst (TYPE_SIZE_UNIT (type), 1) / UNITS_PER_WORD;
>>> +  location_t loc = gimple_location (gsi_stmt (*gsi));
>>> +
>>> +  warning_at (loc, OPT_Wvector_operation_expanded,
>>> +             "vector operation will be expanded in parallel");
>>>
>>> what's the difference between 'piecewise' and 'in parallel'?
>>
>> Parallel is a little bit better for performance than piecewise.
>
> I see.  That difference should probably be documented, maybe with
> an example.
>
> Richard.
>
>>> @@ -301,16 +309,15 @@ expand_vector_addition (gimple_stmt_iter
>>>  {
>>>   int parts_per_word = UNITS_PER_WORD
>>>                       / tree_low_cst (TYPE_SIZE_UNIT (TREE_TYPE (type)), 1);
>>> +  location_t loc = gimple_location (gsi_stmt (*gsi));
>>>
>>>   if (INTEGRAL_TYPE_P (TREE_TYPE (type))
>>>       && parts_per_word >= 4
>>>       && TYPE_VECTOR_SUBPARTS (type) >= 4)
>>> -    return expand_vector_parallel (gsi, f_parallel,
>>> -                                  type, a, b, code);
>>> +    return expand_vector_parallel (gsi, f_parallel, type, a, b, code);
>>>   else
>>> -    return expand_vector_piecewise (gsi, f,
>>> -                                   type, TREE_TYPE (type),
>>> -                                   a, b, code);
>>> +    return expand_vector_piecewise (gsi, f, type,
>>> +                                   TREE_TYPE (type), a, b, code);
>>>  }
>>>
>>>  /* Check if vector VEC consists of all the equal elements and
>>>
>>> unless i miss something loc is unused here.  Please avoid random
>>> whitespace changes (just review your patch yourself before posting
>>> and revert pieces that do nothing).
>>
>> Yes you are right, sorry.
>>
>>> +@item -Wvector-operation-expanded
>>> +@opindex Wvector-operation-expanded
>>> +@opindex Wno-vector-operation-expanded
>>> +Warn if vector operation is not implemented via SIMD capabilities of the
>>> +architecture. Mainly useful for the performance tuning.
>>>
>>> I'd mention that this is for vector operations as of the C extension
>>> documented in "Vector Extensions".
>>>
>>> The vectorizer can produce some operations that will need further
>>> lowering - we probably should make sure to _not_ warn about those.
>>> Try running the vect.exp testsuite with the new warning turned on
>>> (eventually disabling SSE), like with
>>>
>>> obj/gcc> make check-gcc
>>> RUNTESTFLAGS="--target_board=unix/-Wvector-extensions/-mno-sse
>>> vect.exp"
>>
>> Again, see the comment above. I think, if the warning can be triggered
>> only manually, then we are fine. But I'll check anyway how many
>> warnings I'll get from vect.exp.
>>
>>>> P.S. It is hard to write a reasonable testcase for the patch, because
>>>> one needs to guess which architecture would expand a given vector
>>>> operation. But the patch is trivial.
>>>
>>> You can create an aritificial large vector type for example, or put a
>>> testcase under gcc.target/i386 and disable SSE.  We should have
>>> a testcase for this.
>>
>> Yeah, disabling SSE should help.
>>
>>
>> Thanks,
>> Artem.
>>> Thanks,
>>> Richard.
>>>
>>
>

New version of the patch in the attachment with the test-cases.
Bootstrapped on  x86_64-apple-darwin10.8.0.
Currently is being tested.


Richard, I've checked the vect.exp case, as you suggested.  It caused
a lot of failures, but not because of the new warning.  The main
reason is -mno-sse.  The target is capable to vectorize, so the dg
option expects tests to pass, but the artificial option makes them
fail.  Checking the new warning on vect.exp without -mno-sse, it
didn't cause any new failures.  Anyway, we should be pretty much safe,
cause the warning is not a part of -O3.

Thanks,
Artem.

[-- Attachment #2: vector-op-warning-1.diff --]
[-- Type: application/octet-stream, Size: 9719 bytes --]

Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 179636)
+++ gcc/doc/invoke.texi	(working copy)
@@ -271,7 +271,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wunused-label  -Wunused-local-typedefs -Wunused-parameter @gol
 -Wno-unused-result -Wunused-value @gol -Wunused-variable @gol
 -Wunused-but-set-parameter -Wunused-but-set-variable @gol
--Wvariadic-macros -Wvla -Wvolatile-register-var  -Wwrite-strings}
+-Wvariadic-macros -Wvector-operation-performance -Wvla 
+-Wvolatile-register-var  -Wwrite-strings}
 
 @item C and Objective-C-only Warning Options
 @gccoptlist{-Wbad-function-cast  -Wmissing-declarations @gol
@@ -4535,6 +4536,18 @@ Warn if variadic macros are used in peda
 alternate syntax when in pedantic ISO C99 mode.  This is default.
 To inhibit the warning messages, use @option{-Wno-variadic-macros}.
 
+@item -Wvector-operation-performance
+@opindex Wvector-operation-performance
+@opindex Wno-vector-operation-performance
+Warn if vector operation is not implemented via SIMD capabilities of the
+architecture.  Mainly useful for the performance tuning.
+Vector operation can be implemented @code{piecewise} which means that the
+scalar operation is performed on every vector element; 
+@code{in parallel} which means that the vector operation is implemented
+using scalars of wider type, which normally is more performance efficient;
+and @code{as a single scalar} which means that vector fits into a
+scalar type.
+
 @item -Wvla
 @opindex Wvla
 @opindex Wno-vla
Index: gcc/testsuite/gcc.target/i386/warn-vect-op-3.c
===================================================================
--- gcc/testsuite/gcc.target/i386/warn-vect-op-3.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/warn-vect-op-3.c	(revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do compile }  */
+/* { dg-options "-mno-sse -Wvector-operation-performance" }  */
+#define vector(elcount, type)  \
+__attribute__((vector_size((elcount)*sizeof(type)))) type
+
+int main (int argc, char *argv[])
+{
+  vector (8, short) v0 = {argc, 1, 15, 38, 12, -1, argc, 2};
+  vector (8, short) v1 = {-4, argc, 2, 11, 1, 17, -8, argc};
+  vector (8, short) res[] = 
+  {
+    v0 + v1,	      /* { dg-warning "expanded in parallel" }  */
+    v0 - v1,          /* { dg-warning "expanded in parallel" }  */
+    v0 > v1,          /* { dg-warning "expanded piecewise" }  */
+    v0 & v1,          /* { dg-warning "expanded in parallel" }  */
+    __builtin_shuffle (v0, v1),	      /* { dg-warning "expanded piecewise" }  */
+    __builtin_shuffle (v0, v1, v1)    /* { dg-warning "expanded piecewise" }  */
+  };
+  
+  return res[argc][argc];
+}
Index: gcc/testsuite/gcc.target/i386/warn-vect-op-1.c
===================================================================
--- gcc/testsuite/gcc.target/i386/warn-vect-op-1.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/warn-vect-op-1.c	(revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do compile }  */
+/* { dg-options "-mno-sse -Wvector-operation-performance" }  */
+#define vector(elcount, type)  \
+__attribute__((vector_size((elcount)*sizeof(type)))) type
+
+int main (int argc, char *argv[])
+{
+  vector (4, int) v0 = {argc, 1, 15, 38};
+  vector (4, int) v1 = {-4, argc, 2, 11};
+  vector (4, int) res[] = 
+  {
+    v0 + v1,	  /* { dg-warning "expanded piecewise" }  */
+    v0 - v1,	  /* { dg-warning "expanded piecewise" }  */
+    v0 > v1,	  /* { dg-warning "expanded piecewise" }  */
+    v0 & v1,	  /* { dg-warning "expanded in parallel" }  */
+    __builtin_shuffle (v0, v1),	    /* { dg-warning "expanded piecewise" }  */
+    __builtin_shuffle (v0, v1, v1)  /* { dg-warning "expanded piecewise" }  */  
+  };
+
+  return res[argc][argc];
+}
Index: gcc/testsuite/gcc.target/i386/warn-vect-op-2.c
===================================================================
--- gcc/testsuite/gcc.target/i386/warn-vect-op-2.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/warn-vect-op-2.c	(revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile }  */
+/* { dg-options "-mno-sse -Wvector-operation-performance" }  */
+#define vector(elcount, type)  \
+__attribute__((vector_size((elcount)*sizeof(type)))) type
+
+int main (int argc, char *argv[])
+{
+  vector (16, signed char) v0 = {argc, 1, 15, 38, 12, -1, argc, 2, 
+				 argc, 1, 15, 38, 12, -1, argc, 2};
+  vector (16, signed char) v1 = {-4, argc, 2, 11, 1, 17, -8, argc,
+				 argc, 1, 15, 38, 12, -1, argc, 2};
+  vector (16, signed char) res[] = 
+  {
+    v0 + v1,		  /* { dg-warning "expanded in parallel" }  */
+    v0 - v1,              /* { dg-warning "expanded in parallel" }  */
+    v0 > v1,              /* { dg-warning "expanded piecewise" }  */
+    v0 & v1,              /* { dg-warning "expanded in parallel" }  */
+    __builtin_shuffle (v0, v1),        /* { dg-warning "expanded piecewise" }  */
+    __builtin_shuffle (v0, v1, v1)     /* { dg-warning "expanded piecewise" }  */
+  };
+ 
+  return res[argc][argc];
+}
Index: gcc/common.opt
===================================================================
--- gcc/common.opt	(revision 179636)
+++ gcc/common.opt	(working copy)
@@ -694,6 +694,10 @@ Wcoverage-mismatch
 Common Var(warn_coverage_mismatch) Init(1) Warning
 Warn in case profiles in -fprofile-use do not match
 
+Wvector-operation-performance
+Common Var(warn_vector_operation_performance) Warning
+Warn when a vector operation is compiled outside the SIMD
+
 Xassembler
 Driver Separate
 
Index: gcc/tree-vect-generic.c
===================================================================
--- gcc/tree-vect-generic.c	(revision 179636)
+++ gcc/tree-vect-generic.c	(working copy)
@@ -235,6 +235,14 @@ expand_vector_piecewise (gimple_stmt_ite
   int delta = tree_low_cst (part_width, 1)
 	      / tree_low_cst (TYPE_SIZE (TREE_TYPE (type)), 1);
   int i;
+  location_t loc = gimple_location (gsi_stmt (*gsi));
+
+  if (gimple_expr_type (gsi_stmt (*gsi)) == type)
+    warning_at (loc, OPT_Wvector_operation_performance,
+		"vector operation will be expanded piecewise");
+  else
+    warning_at (loc, OPT_Wvector_operation_performance,
+		"vector operation will be expanded in parallel");
 
   v = VEC_alloc(constructor_elt, gc, (nunits + delta - 1) / delta);
   for (i = 0; i < nunits;
@@ -260,6 +268,7 @@ expand_vector_parallel (gimple_stmt_iter
   tree result, compute_type;
   enum machine_mode mode;
   int n_words = tree_low_cst (TYPE_SIZE_UNIT (type), 1) / UNITS_PER_WORD;
+  location_t loc = gimple_location (gsi_stmt (*gsi));
 
   /* We have three strategies.  If the type is already correct, just do
      the operation an element at a time.  Else, if the vector is wider than
@@ -284,6 +293,9 @@ expand_vector_parallel (gimple_stmt_iter
       mode = mode_for_size (tree_low_cst (TYPE_SIZE (type), 1), MODE_INT, 0);
       compute_type = lang_hooks.types.type_for_mode (mode, 1);
       result = f (gsi, compute_type, a, b, NULL_TREE, NULL_TREE, code);
+      warning_at (loc, OPT_Wvector_operation_performance,
+	          "vector operation will be expanded with a "
+		  "single scalar operation");
     }
 
   return result;
@@ -308,7 +320,7 @@ expand_vector_addition (gimple_stmt_iter
     return expand_vector_parallel (gsi, f_parallel,
 				   type, a, b, code);
   else
-    return expand_vector_piecewise (gsi, f,
+    return expand_vector_piecewise (gsi, f, 
 				    type, TREE_TYPE (type),
 				    a, b, code);
 }
@@ -400,8 +412,8 @@ expand_vector_operation (gimple_stmt_ite
       case PLUS_EXPR:
       case MINUS_EXPR:
         if (!TYPE_OVERFLOW_TRAPS (type))
-          return expand_vector_addition (gsi, do_binop, do_plus_minus, type,
-		      		         gimple_assign_rhs1 (assign),
+	  return expand_vector_addition (gsi, do_binop, do_plus_minus, type,
+					 gimple_assign_rhs1 (assign),
 					 gimple_assign_rhs2 (assign), code);
 	break;
 
@@ -626,10 +638,14 @@ lower_vec_shuffle (gimple_stmt_iterator 
   tree constr, t, si, i_val;
   tree vec0tmp = NULL_TREE, vec1tmp = NULL_TREE, masktmp = NULL_TREE;
   bool two_operand_p = !operand_equal_p (vec0, vec1, 0);
+  location_t loc = gimple_location (gsi_stmt (*gsi));
   unsigned i;
 
   if (expand_vec_shuffle_expr_p (TYPE_MODE (vect_type), vec0, vec1, mask))
     return;
+  
+  warning_at (loc, OPT_Wvector_operation_performance,
+              "vector shuffling operation will be expanded piecewise");
 
   v = VEC_alloc (constructor_elt, gc, elements);
   for (i = 0; i < elements; i++)
Index: gcc/c-parser.c
===================================================================
--- gcc/c-parser.c	(revision 179636)
+++ gcc/c-parser.c	(working copy)
@@ -6533,17 +6533,22 @@ c_parser_postfix_expression (c_parser *p
 	      }
 
 	    if (VEC_length (c_expr_t, cexpr_list) == 2)
-	      expr.value =
-		c_build_vec_shuffle_expr
-		  (loc, VEC_index (c_expr_t, cexpr_list, 0)->value,
-		   NULL_TREE, VEC_index (c_expr_t, cexpr_list, 1)->value);
-
+	      {
+		expr.value =
+		  c_build_vec_shuffle_expr
+		    (loc, VEC_index (c_expr_t, cexpr_list, 0)->value,
+		     NULL_TREE, VEC_index (c_expr_t, cexpr_list, 1)->value);
+		SET_EXPR_LOCATION (expr.value, loc);
+	      }
 	    else if (VEC_length (c_expr_t, cexpr_list) == 3)
-	      expr.value =
-		c_build_vec_shuffle_expr
-		  (loc, VEC_index (c_expr_t, cexpr_list, 0)->value,
-		   VEC_index (c_expr_t, cexpr_list, 1)->value,
-		   VEC_index (c_expr_t, cexpr_list, 2)->value);
+	      {
+		expr.value =
+		  c_build_vec_shuffle_expr
+		    (loc, VEC_index (c_expr_t, cexpr_list, 0)->value,
+		     VEC_index (c_expr_t, cexpr_list, 1)->value,
+		     VEC_index (c_expr_t, cexpr_list, 2)->value);
+		SET_EXPR_LOCATION (expr.value, loc);
+	      }
 	    else
 	      {
 		error_at (loc, "wrong number of arguments to "

  reply	other threads:[~2011-10-07  5:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-04 22:25 Artem Shinkarov
2011-10-05  8:40 ` Richard Guenther
2011-10-05 11:31   ` Artem Shinkarov
2011-10-05 11:37     ` Richard Guenther
2011-10-07  7:13       ` Artem Shinkarov [this message]
2011-10-07  8:01         ` Artem Shinkarov
2011-10-10 11:15           ` Richard Guenther
2011-10-10 13:27             ` Artem Shinkarov
2011-10-11 11:40               ` Richard Guenther
2011-10-11 17:26                 ` Artem Shinkarov
2011-10-12 16:25                   ` H.J. Lu
2011-10-12 22:10                     ` Artem Shinkarov
2011-10-13  9:32                       ` Mike Stump
2011-10-13 10:17                         ` Richard Guenther
2011-10-13 10:18                           ` Artem Shinkarov
2011-10-14 14:02                             ` Artem Shinkarov
2011-10-14 14:15                               ` Richard Guenther
2011-10-14 16:05                                 ` Artem Shinkarov
2011-10-14 18:31                                   ` Mike Stump

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='CABYV9SXXoXQs4ER3nP_JDVWE0KcrJZB6dWw5h3GC=ZaxgGuvLw@mail.gmail.com' \
    --to=artyom.shinkaroff@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).