This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: combine permutations in gimple
On Mon, Aug 13, 2012 at 4:12 PM, Ramana Radhakrishnan
<ramana.radhakrishnan@linaro.org> wrote:
> On 13 August 2012 14:54, Jakub Jelinek <jakub@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