On 13 August 2012 14:54, Jakub Jelinek <ja...@redhat.com> wrote: > 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.
Maybe we need an interface of that form. A generic permute operation used for constant permute operations is going to be more expensive than more specialized constant permute operations. It might be that this cost gets amortized over a large number of operations at which point it makes sense but the compiler should make this transformation based on cost rather than just whether something is supported or not. Ramana
