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
p
Ah, I didn't realize Loongson was little-endian only. In that case (with mid-end
reductions-via-shifts changes pushed) I don't think I have actually broken
anything, or at least, no MIPS platform that exists :).
However, yes, that would seem a safe bet (and simpler than my linked patch that
pr
> (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;
I will post a patch to remove vec_shl and only support vec_shr for
little endian. This is on the
On Wed, 12 Nov 2014, Alan Lawrence wrote:
> 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
On Thu, 13 Nov 2014, Alan Lawrence wrote:
> Hmmm, I see. Yes, that would be another way. It has me wondering however
> exactly where to draw the line, as to what permutations
> TARGET_VECTORIZE_VEC_PERM_CONST_OK should allow / how much effort it should
> go to. For example, should said hook return
