[patch] [4.2 projects] vectorize type conversions - 5/6

[Diego Novillo]

Dorit Nuzman wrote on 02/12/06 08:48:
> Support vectorization in the presence of data-types of different sizes.
> This part adds support for vectorization of type demotion.
> 
Meta question about all these patches: Have you noticed any performance
changes?  Which benchmarks?

> +   scalar_dest = TREE_OPERAND (stmt, 0);
> +   scalar_type = TREE_TYPE (scalar_dest);
> +   vectype_out = get_vectype_for_scalar_type (scalar_type);
> +   nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
> +   if (nunits_in != nunits_out/2) /* FORNOW */
>
Spacing 'nunits_out / 2'.  What if nunits_in == 2 and nunits_out == 5?
Perhaps it's safer to check 'nunits_in * 2 == nunits_out'.

> +   /** Transform.  **/
> + 
Use /* */



> +       /* Arguments are ready. Create the new vector stmt.  */
> +       expr = build2 (code, vectype_out, vec_oprnd0, vec_oprnd1);
> +       new_stmt = build2 (MODIFY_EXPR, vectype_out, vec_dest, expr);
>
s/vectype_out/void_type_node/

> !       if (binoptab == vec_pack_mod_optab || binoptab == vec_pack_usat_optab
> !           || binoptab == vec_pack_ssat_optab)
> ! 	{
>
Line-up predicates vertically.

> ! 	  /* The mode of the result is different then the mode of the
> ! 	     arguments.  */
> ! 	  tmp_mode = insn_data[icode].operand[0].mode;
> ! 	  if (GET_MODE_NUNITS (tmp_mode) != 2*GET_MODE_NUNITS (mode))
>
2 * GET_MODE_NUNITS (mode)


> *************** dump_generic_node (pretty_printer *buffe
> *** 1858,1863 ****
> --- 1858,1879 ----
>         pp_string (buffer, " > ");
>         break;
>   
> +     case VEC_PACK_MOD_EXPR:
> +       pp_string (buffer, " VEC_PACK_MOD_EXPR < ");
> +       dump_generic_node (buffer, TREE_OPERAND (node, 0), spc, flags, false);
> +       pp_string (buffer, " , ");
>
s/" , "/", "/

> +       dump_generic_node (buffer, TREE_OPERAND (node, 1), spc, flags, false);
> +       pp_string (buffer, " > ");
> +       break;
> +                                                                                 
> +     case VEC_PACK_SAT_EXPR:
> +       pp_string (buffer, " VEC_PACK_SAT_EXPR < ");
> +       dump_generic_node (buffer, TREE_OPERAND (node, 0), spc, flags, false);
> +       pp_string (buffer, " , ");
>
s/" , "/", "/


> Index: testsuite/lib/target-supports.exp
> ===================================================================
> *** testsuite/lib/target-supports.exp	(revision 110645)
> --- testsuite/lib/target-supports.exp	(working copy)
> *************** proc check_effective_target_vect_udot_hi
> *** 1540,1545 ****
> --- 1540,1570 ----
>   }
>   
>   
> + # Return 1 if the target plus current options supports a vector
> + # demotion (packing) of shorts (to chars) and ints (to shorts) 
> + # using modulo arithmetic, 0 otherwise.
> + #
> + # This won't change for different subtargets so cache the result.
> +                                                                                 
> + proc check_effective_target_vect_pack_mod { } {
> +     global et_vect_pack_mod
> +                                                                                 
> +     if [info exists et_vect_pack_mod_saved] {
> +         verbose "check_effective_target_vect_pack_mod: using cached result" 2
> +     } else {
> +         set et_vect_pack_mod_saved 0
> +         if { [istarget powerpc*-*-*]
> +              || [istarget i?86-*-*]
> +              || [istarget x86_64-*-*]
> +              || [istarget ia64-*-*] } {
> +             set et_vect_pack_mod_saved 1
> +         }
> +     }
> +     verbose "check_effective_target_vect_pack_mod: returning $et_vect_pack_mod_saved" 2
> +     return $et_vect_pack_mod_saved
> + }
> + 
> + 
>   # Return 1 if the target plus current options does not support a vector
>   # alignment mechanism, 0 otherwise.
>   #
>
I'm going to guess that this is fine, but I'm not completely sure.  Janis?

> Index: doc/md.texi
> ===================================================================
> *** doc/md.texi	(revision 110645)
> --- doc/md.texi	(working copy)
> *************** Operand 2 is an integer shift amount in 
> *** 3148,3153 ****
> --- 3148,3163 ----
>   Operand 0 is where the resulting shifted vector is stored.
>   The output and input vectors should have the same modes.
>   
> + @cindex @code{vec_pack_mod_@var{m}} instruction pattern
> + @cindex @code{vec_pack_ssat_@var{m}} instruction pattern
> + @cindex @code{vec_pack_usat_@var{m}} instruction pattern
> + @item @samp{vec_pack_mod_@var{m}}, @samp{vec_pack_ssat_@var{m}}, @samp{vec_pack_usat_@var{m}}
> + Narrow (demote) and merge the elements of two vectors.
> + Operands 1 and 2 are vectors of the same mode.
> + Operand 0 is the resulting vector in which the elements of the two input
> + vectors are concatenated after narrowing them down using modulo arithmetic or
> + signed/unsigned saturating arithmetic.
> + 
>   @cindex @code{mulhisi3} instruction pattern
>   @item @samp{mulhisi3}
>   Multiply operands 1 and 2, which have mode @code{HImode}, and store
>
You are missing c-tree.texi documentation on the new GIMPLE nodes.


OK with those changes.


:REVIEWMAIL: