This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: combine permutations in gimple


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.

Ramana


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]