[patch] vectorizer: fix handling of non VECTOR_MODE_P vectypes

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> > so it should return a V2SI vectype, which is not supported by the
target
> > and therefore should have a BLKmode. no?
>
> Nope.  An integer mode is returned if we have one that fits.  It
> makes the routines in tree-complex.c happy.

In this case we also need to fix the computation of the vectorization
factor - currently it is set to GET_MODE_NUNITS, which is correct only if
the mode is VECTOR_MODE_P. This came up on ppc-darwin compiling SPEC's
crafty - build_vector_type returned TImode for a 'long long' type, and the
vectorization factor was set to 1 instead of 2. Crafty failed as a result.
(Ideally build_vector_type would have returned BLKmode rather than TImode;
see machmode.def: "FIXME TI shouldn't be generically available either.  *".
I didn't fail vectorization in this case, although this type is not really
supported and the vectorization will be undone later on).

Bootstrapped and tested on ppc-darwin. ok for mainline?

thanks,
dorit

        * tree-vectorizer.c (get_vectype_for_scalar_type): Added debug
printouts.
        Added checks under ENABLE_CHECKING to verify the vectorizer's
        assumptions on the vectype returned by build_vector_type. Check if
TImode.
        (vect_transform_loop): Added gcc_assert under ENABLE_CHECKING.
        (vect_analyze_operations): Don't use GET_MODE_NUNITS to determine
the
        vectorization factor. Make sure the vectorization factor > 1. Add
        gcc_assert under ENABLE_CHECKING.
        (vect_get_vec_def_for_operand): Remove redundant variables.

(See attached file: vectfix2)





|---------+---------------------------->
|         |           Paolo Bonzini    |
|         |           <bonzini@gnu.org>|
|         |                            |
|         |           29/09/2004 11:17 |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                            |
  |       To:       Paolo Bonzini <bonzini@gnu.org>, Richard Henderson <rth@redhat.com>, Dorit Naishlos/Haifa/IBM@IBMIL        |
  |       cc:       Chao-ying Fu <fu@mips.com>, gcc-patches@gcc.gnu.org, "Stephens, Nigel" <nigel@mercury.mips.com>, "Thekkath,|
  |        Radhika" <radhika@mercury.mips.com>, Richard Sandiford <rsandifo@redhat.com>, "Uhler, Mike"                         |
  |        <uhler@mercury.mips.com>, Jim Wilson <wilson@specifixinc.com>                                                       |
  |       Subject:  Re: [patch] extend.texi MIPS PS/3D Support                                                                 |
  >----------------------------------------------------------------------------------------------------------------------------|




> Yes, it should.  Generic vectors should not be created by the vectorizer
> (yet).

Ah, I thought that the vectorizer created its vector types with a
separate routine, but that has been fixed a while ago.  The attached
patch should help.

It was bootstrapped and passes the vectorizer testsuite.  Full regtest
on i686-pc-linux-gnu is in progress.  Ok for mainline?

Paolo

2004-09-29  Paolo Bonzini  <bonzini@gnu.org>

             * tree-vectorizer.c (vectorizable_operation): Only look at the
             optab in the case of vector modes; otherwise, bail out.
Index: tree-vectorizer.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.12
diff -u -r2.12 tree-vectorizer.c
--- tree-vectorizer.c          25 Sep 2004 14:48:03 -0000          2.12
+++ tree-vectorizer.c          29 Sep 2004 07:31:24 -0000
@@ -1408,6 +1408,17 @@
       return false;
     }
   vec_mode = TYPE_MODE (vectype);
+  if (GET_MODE_CLASS (vec_mode) != MODE_VECTOR_INT
+      && GET_MODE_CLASS (vec_mode) != MODE_VECTOR_FLOAT)
+    {
+      /* TODO: tree-complex.c sometimes can parallelize operations
+             on generic vectors.  We can vectorize the loop in that case,
+             but then we should re-run the lowering pass.  */
+      if (vect_debug_details (NULL))
+            fprintf (dump_file, "vector mode not supported by target.");
+      return false;
+    }
+
   if (optab->handlers[(int) vec_mode].insn_code == CODE_FOR_nothing)
     {
       if (vect_debug_details (NULL))

Attachment: vectfix2
Description: Binary data