On Wed, 15 Aug 2012, Richard Guenther wrote: > On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan > <ramana.radhakrish...@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
