[rs6000,spu] Add vec_perm named pattern

The generic support for vector permutation will allow for automatic
lowering to V*QImode, so all we need to add to support for these targets
is the single V16QI pattern that represents the base permutation insn.

I'm not touching any of the other ways that the permutation insn 
could be generated.  After the generic support is added, I'll leave
it to the port maintainers to determine what they want to keep.  I
suspect in many cases using the generic __builtin_shuffle plus some
casting in the target-specific header files would be sufficient,
eliminating several dozen builtins.


Ok?


r~


	* config/rs6000/altivec.md (vec_permv16qi): New.

	* config/spu/spu.md (vec_permv16qi): New.
commit f2d8929afb989a09d7e287dc171607440bbbbc1a
Author: Richard Henderson <rth@twiddle.net>
Date:   Mon Oct 10 12:35:25 2011 -0700

    rs6000: Implement vec_permv16qi.
commit a67ea08189a4399d6ade00c15e69447304f85f96
Author: Richard Henderson <rth@twiddle.net>
Date:   Mon Oct 10 12:35:50 2011 -0700

    spu: Implement vec_permv16qi.

diff --git a/gcc/config/spu/spu.md b/gcc/config/spu/spu.md
index 676d54e..00cfaa4 100644
--- a/gcc/config/spu/spu.md
+++ b/gcc/config/spu/spu.md
@@ -4395,6 +4395,18 @@ selb\t%0,%4,%0,%3"
   "shufb\t%0,%1,%2,%3"
   [(set_attr "type" "shuf")])
 
+(define_expand "vec_permv16qi"
+  [(set (match_operand:V16QI 0 "spu_reg_operand" "")
+	(unspec:V16QI
+	  [(match_operand:V16QI 1 "spu_reg_operand" "")
+	   (match_operand:V16QI 2 "spu_reg_operand" "")
+	   (match_operand:V16QI 3 "spu_reg_operand" "")]
+	  UNSPEC_SHUFB))]
+  ""
+  {
+    operands[3] = gen_lowpart (TImode, operands[3]);
+  })
+
 (define_insn "nop"
   [(unspec_volatile [(const_int 0)] UNSPECV_NOP)]
   ""

On Wed, Oct 12, 2011 at 03:42:12PM -0700, Richard Henderson wrote:
> The generic support for vector permutation will allow for automatic
> lowering to V*QImode, so all we need to add to support for these targets
> is the single V16QI pattern that represents the base permutation insn.
> 
> I'm not touching any of the other ways that the permutation insn 
> could be generated.  After the generic support is added, I'll leave
> it to the port maintainers to determine what they want to keep.  I
> suspect in many cases using the generic __builtin_shuffle plus some
> casting in the target-specific header files would be sufficient,
> eliminating several dozen builtins.
> 
> 
> Ok?

I would rather change altivec_vperm_<mode> to use the new name (and also
altivec_vperm_<mode>_uns).  But I can live with a wrapper function for now.

If we are adding permute options, can we please get the vectorizer to use
optabs instead of using the targetm.vectorize.builtin_vec_perm hook?  It has
always struck me as a sore thumb that we have a hook that needs to return a
builtin function decl (targetm.vectorize.builtin_mask_for_load also).

On 10/14/2011 12:53 PM, Michael Meissner wrote:
> I would rather change altivec_vperm_<mode> to use the new name (and also
> altivec_vperm_<mode>_uns).  But I can live with a wrapper function for now.

As I said, I'm leaving the cleanup of the old patterns to port maintainers.

> If we are adding permute options, can we please get the vectorizer to use
> optabs instead of using the targetm.vectorize.builtin_vec_perm hook?  It has
> always struck me as a sore thumb that we have a hook that needs to return a
> builtin function decl (targetm.vectorize.builtin_mask_for_load also).

That's exactly what I've been working on today.


r~