This is the mail archive of the 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 Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
> <> wrote:
> >>
> >> I guess people will complain soon enough if this causes horrible performance
> >> regressions in vectorized code.
> >
> > Not having looked at your patch in great detail,. surely what we don't
> > want is a situation where 2 constant permutations are converted into
> > one generic permute. Based on a quick read of your patch I couldn't
> > work that out.  It might be that 2 constant  permutes are cheaper than
> > a generic permute. Have you looked at any examples in that space . I
> > surely wouldn't like to see a sequence of interleave / transpose
> > change into a generic permute operation on Neon as that would be far
> > more expensive than this.  It surely needs more testting than just
> > this bit before going in. The reason being that this would likely take
> > more registers and indeed produce loads of a constant pool for the new
> > mask.
> 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, 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.


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