On Fri, 2015-09-18 at 10:38 +0200, Richard Biener wrote: > On Thu, 17 Sep 2015, Segher Boessenkool wrote: > > > On Thu, Sep 17, 2015 at 09:18:42AM -0500, Bill Schmidt wrote: > > > On Thu, 2015-09-17 at 09:39 +0200, Richard Biener wrote: > > > > So just to clarify - you need to reduce the vector with max to a scalar > > > > but want the (same) result in all vector elements? > > > > > > Yes. Alan Hayward's cond-reduction patch is set up to perform a > > > reduction to scalar, followed by a scalar broadcast to get the value > > > into all positions. It happens that our most efficient expansion to > > > reduce to scalar will naturally produce the value in all positions. > > > > It also is many insns after expand, so relying on combine to combine > > all that plus the following splat (as Richard suggests below) is not > > really going to work. > > > > If there also are targets where the _scal version is cheaper, maybe > > we should keep both, and have expand expand to whatever the target > > supports? > > Wait .. so you don't actually have an instruction to do, say, > REDUC_MAX_EXPR (neither to scalar nor to vector)? Then it's better > to _not_ define such pattern and let the vectorizer generate > its fallback code. If the fallback code isn't "best" then better > think of a way to make it choose the best variant out of its > available ones (and maybe add another). I think it tests > availability of the building blocks for the variants and simply > picks the first that works without checking the cost model.
That's what we were considering per Alan Lawrence's suggestion elsewhere in this thread, but there isn't currently a way to represent a whole-vector rotate in gimple. So we'd either have to add that or fall back to an inferior code sequence, I believe. Bill > > Richard. > > > > > Segher > > > > > > -- > Richard Biener <rguent...@suse.de> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nuernberg) >
