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
