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]

Re: [PATCH, rs6000] Add expansions for min/max vector reductions


On Fri, 18 Sep 2015, Bill Schmidt wrote:

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

A whole-vector rotate is just a VEC_PERM with a proper constant mask.
Of course the target would have to detect these cases and use
vector rotate instructions (x86 does that for example).

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


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