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.
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?
--
Marc Glisse
