On 11/16/2009 06:37 PM, Joern Rennecke wrote:
Variable permutations could be very useful for doing vector operations on
unaligned inputs. To some degrees shifts can be used, but if they only have
C semantics you'll get corner cases with word-sized shifts when the
input is actually aligned.
I'm
...
>
> >
> > I'm contemplating adding a tree- and gimple-level VEC_PERMUTE_EXPR of
> > the form:
> >
> >VEC_PERMUTE_EXPR (vlow, vhigh, vperm)
> >
> > which would be exactly equal to
> >
> >(vec_select
> > (vec_concat vlow vhigh)
> > vperm)
> >
> > at the rtl level. I.e. vperm is
> > I can imagine having some sort of target hook that computed a cost
> > metric for a given constant permutation pattern. For instance, I'd
> > imagine that the interleave patterns are half as expensive as a full
> > permute for altivec, due to not having to load a mask. This hook would
> > be
Richard Henderson wrote on 17/11/2009 03:39:42:
> Richard Henderson
> 17/11/2009 03:39
>
> To
>
> Ira Rosen/Haifa/i...@ibmil
>
> cc
>
> gcc@gcc.gnu.org
>
> Subject
>
> targetm.vectorize.builtin_vec_perm
>
> What is this hook supposed to do? There is no description of its
arguments.
>
> What i
Quoting Richard Henderson :
Truly variable permutation is something that's only supported by ppc
and spu.
SH64 also has variable permutation. 16 bit elements within its 64 bit
vector size can be permuted.
HOWEVER! Most of the useful permutations that I can think of for the
optimizers to ge
