On Mon, Aug 13, 2012 at 4:12 PM, Ramana Radhakrishnan <ramana.radhakrish...@linaro.org> wrote: > 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.
Well. I think the middle-end can reasonably assume that backends know how to most efficiently perform any constant permute. We do not limit converting a = a + 5; a = a + 254; to a = a + 259; either though a target may generate better code for the first case. Which means that we should go without a target test and take regressions as they appear as an opportunity to improve targets instead. Richard. > Ramana
