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

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