On Thu, Sep 18, 2014 at 2:27 PM, Alan Lawrence <alan.lawre...@arm.com> wrote: > The VEC_RSHIFT_EXPR is only ever used by the vectorizer in tree-vect-loop.c > (vect_create_epilog_for_reduction), to shift the vector by a whole number of > elements. The tree code allows more general shifts but only for integral > types. This only causes pain and difficulty for backends (particularly for > backends with different endiannesses), and enforcing that restriction for > integral types too does no harm. > > bootstrapped on aarch64-none-linux-gnu and x86-64-none-linux-gnu > check-gcc on aarch64-none-elf and x86_64-none-linux-gnu
Hmm, but then (coming from the tree / gimple level) all shifts can be expressed with a VEC_PERM_EXPR. And of course a general whole-vector shift could be expressed using a VIEW_CONVERT_EXPR to a 1-element integer vector and a regular [RL]SHIFT_EXPR and then converting back. So it seems to me that the vectorizer should instead emit a VEC_PERM_EXPR (making sure the backends or the generic vec_perm expansion code in optabs.c handles the whole-vector-shift case in an optimal way). The current VEC_RSHIFT_EXPR description lacks information on what is shifted in btw (always zeros? the most significant bit (endian dependent?!)). So - can we instead remove VEC_[LR]SHIFT_EXPR? Seems that VEC_LSHIFT_EXPR is unused anyway, and thus vec_shl_optabs as well. Thanks, Richard. > gcc/ChangeLog: > > * tree-cfg.c (verify_gimple_assign_binary): for VEC_RSHIFT_EXPR (and > VEC_LSHIFT_EXPR), require shifts to be by a whole number of elements > for all types, rather than only non-integral types. > > * tree.def (VEC_LSHIFT_EXPR, VEC_RSHIFT_EXPR): Update comment. > > * doc/md.texi (vec_shl_m, vec_shr_m): Update comment. >
