On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>
> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> >>The patch does not do that. It merely assumes that the target knows
> >>how to perform an optimal constant permute and that two constant
> >>permutes never generate better code than a single one.
> >
> >Still, the patch should do some tests whether it is beneficial.
> >At least a can_vec_perm_p (mode, false, sel) test of the resulting
> >permutation if both the original permutations pass that test,
>
> Sounds good. The last argument should be the constant permutation
> vector, presented as an array of indices stored in unsigned char? I
> hadn't realized we already had access to backend information that
> early in the compilation. It doesn't give the cost though.
Yeah, it doesn't give the cost, just whether it is supported at all.
> >and perhaps
> >additionally if targetm.vectorize.vec_perm_const_ok is non-NULL and
> >passes for both the original permutations then it should also pass
> >for the resulting permutation.
>
> Isn't that implied by the previous test (I see calls to
> vec_perm_const_ok in there)? Or maybe not quite?
can_vec_perm_p can also return true if e.g. the target supports generic
variable permutation for the mode in question.
So the targetm.vectorize.vec_perm_const_ok check is stricter than that,
it tells you whether it can be supported by some constant permutation (or a
sequence of them, you know how the i386 code for that is complicated).
Jakub
