[PATCH 0/4][Vectorizer] Reductions: replace VEC_RSHIFT_EXPR with VEC_PERM_EXPR

[Alan Lawrence]

In response to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01803.html, this 
series removes the VEC_RSHIFT_EXPR, instead using a VEC_PERM_EXPR (with a second 
argument full of constant zeroes) to represent the shift.

I've kept the use of vec_shr optab for platforms that define it, as even on 
platforms with a whole-vector-shift operation, this typically does not work as a 
vec-perm on arbitrary vectors (the shift will pull in zeroes from the end, 
whereas TARGET_VECTORIZE_VEC_PERM_CONST_OK and related machinery allows only to 
check for a shift-like permutation that will work for two arbitrary vectors).

I've also changed from the endianness-dependent shift direction of the old 
VEC_RSHIFT_EXPR, to an endian-neutral direction (VEC_PERM_EXPR is inherently 
endian-neutral), changing the meaning of vec_shr_optab to match (as I did in 
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01475.html). As previously, this 
will break any *bigendian* platform defining vec_shr; I see MIPS and RS6000, but 
candidate fixes for both of these have already been posted:

(for MIPS) https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01481.html, although I 
have not been able to test this as there doesn't seem to be any working 
MIPS/Loongson hardware in the Compile Farm;

(for PowerPC) https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01480.html, testing 
in progress.

ARM defines vec_shr only for little-endian; AArch64 does not yet, although in 
previous patch series I both added a vec_shr and made it endian-neutral (I will 
post revised patches for both of these shortly).

Bootstrapped and check-gcc on x86-none-linux-gnu and arm-none-linux-gnu;
cross-tested on aarch64{,_be}-none-elf (FWIW, both with and without previous 
patches adding a vec_shr pattern)

Ok for trunk if no regressions on PowerPC?

Thanks, Alan