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] |

*From*: Hans-Peter Nilsson <hp at bitrange dot com>*To*: Richard Guenther <richard dot guenther at gmail dot com>*Cc*: Ramana Radhakrishnan <ramana dot radhakrishnan at linaro dot org>, Marc Glisse <marc dot glisse at inria dot fr>, gcc-patches at gcc dot gnu dot org*Date*: Thu, 16 Aug 2012 23:02:44 -0400 (EDT)*Subject*: Re: combine permutations in gimple*References*: <alpine.DEB.2.02.1208102312390.13110@stedding.saclay.inria.fr> <alpine.DEB.2.02.1208111417100.26487@stedding.saclay.inria.fr> <CAFiYyc1nH_kLCshNRdbpLstfvtOFTb8fEjvHwo65quBeDYuUqw@mail.gmail.com> <alpine.DEB.2.02.1208131436460.3258@laptop-mg.saclay.inria.fr> <CACUk7=U-zL6cP1cM=sg2=m6FXodHDaOPC5Vz5enOoU8fHK9BhQ@mail.gmail.com> <CAFiYyc0wMYiLbyFQj-+bLNoeHLKekKpRA=Xbp++5hKhdU2f7fg@mail.gmail.com> <alpine.DEB.2.02.1208131515210.3258@laptop-mg.saclay.inria.fr> <CACUk7=XxDwvz8gRnxoEk+=2wvdGzv3zL48LDS=W7f4z-7PQaRw@mail.gmail.com> <alpine.DEB.2.02.1208131613110.3258@laptop-mg.saclay.inria.fr> <CACUk7=U6-xYAa2s-ANziPiJOsS8CLWAFV5ZGgFc4eiSqdVU-jQ@mail.gmail.com> <CAFiYyc3-8p7a-HjS7bi7pxfb6FkqZtGNmvcDU7Q413Er6BOgrg@mail.gmail.com>

On Wed, 15 Aug 2012, Richard Guenther wrote: > On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan > <ramana.radhakrishnan@linaro.org> wrote: > > Of-course, the problem here is this change of semantics with the hook > > TARGET_VEC_PERM_CONST_OK. Targets were expanding to generic permutes > > with constants in the *absence* of being able to deal with them with > > the specialized permutes. fwprop will now leave us at a point where > > each target has to now grow more knowledge with respect to how best to > > expand a generic constant permute with a sequence of permutes rather > > than just using the generic permute. > > > > Generating a sequence of permutes from a single constant permute will > > be a harder problem than (say) dealing with immediate expansions so > > you are pushing more complexity into the target but in the short term > > target maintainers should definitely have a heads up that folks using > > vector permute intrinsics could actually have performance regressions > > on their targets. > > It's of course the same with the user input containing such a non-optimal > handled constant permute. So I'm less convinced that it's too much burden > on the target side. OTOH if there is a generic kind of shuffles that targets > do not implement directly but can be simulated by two that are directly > implemented pushing the logic to the expander (and adjusting the target > hook semantic) would be ok. There's a wonderful knapsack-class problem in there, something for next year's GSoC? (Given a constant permutation, synthesize it with a set of simpler operations with total cost < constant_shuffle, where the "simpler operation" and "costs" are target-specific (query for presence by TARGET_VEC_PERM_CONST_OK and cost hooks; decompose to "simpler operation" by generic heuristics). A similar but simpler problem is to synthesize a constant vector instead of loading it from memory (though a load may be cheap enough for most SIMD targets that this may be uninteresting to generalize). brgds, H-P

**References**:**combine permutations in gimple***From:*Marc Glisse

**Re: combine permutations in gimple***From:*Marc Glisse

**Re: combine permutations in gimple***From:*Richard Guenther

**Re: combine permutations in gimple***From:*Marc Glisse

**Re: combine permutations in gimple***From:*Ramana Radhakrishnan

**Re: combine permutations in gimple***From:*Richard Guenther

**Re: combine permutations in gimple***From:*Marc Glisse

**Re: combine permutations in gimple***From:*Ramana Radhakrishnan

**Re: combine permutations in gimple***From:*Marc Glisse

**Re: combine permutations in gimple***From:*Ramana Radhakrishnan

**Re: combine permutations in gimple***From:*Richard Guenther

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |