[PATCH] Make xxsplti*, xpermx, xxeval be vecperm type.

Michael Meissner meissner@linux.ibm.com
Wed Aug 25 22:42:50 GMT 2021


On Wed, Aug 25, 2021 at 05:29:22PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 25, 2021 at 02:22:06PM -0400, Michael Meissner wrote:
> > On Wed, Aug 25, 2021 at 12:44:16PM -0500, Segher Boessenkool wrote:
> > > Out of interest, did you notice any scheduling differences with this?
> > 
> > I don't use the built-ins so I wouldn't notice a difference.  I noticed this as
> > part of the next patch to add support for XXSPLTIDP (and ultimately XXSPLTIW in
> > a future patch).  The XXSPLTIDP instruction allows loading up many SFmode,
> > DFmode, and V2DFmode constants.  The XXSPLTIW instruction allows loading up
> > certain V16QImode, V8HImode, V4SImode, and V4SFmode constants.
> 
> Yeah, you might notice scheduling differences when "normal" code starts
> using this.  Builtins are meh :-)

Yep, that's my thought.  It just noticed the vecsimple stuff as I was adding
the xxsplti{w,dp,32dx} support.

> > However, I suspect if you aren't running spec on an otherwise
> > idle machine, things will change where XXSPLTIDP will be more of a win by
> > eliminating the loads.
> 
> It has more bandwidth and it is less contested, yup.  It does have the
> usual "prefixed" gotchas though.

Note, it replaces one prefixed instruction (plfd) with another (xxspltidp).

> > While XXSPLTIDP by itself is positive, unfortunately, there is a regression in
> > cactuBSSN_r (3%) when I add XXSPLTIW (but not XXSPLTIDP) that I'm trying to
> > track down.
> > 
> > If I add both instructions, several of the benchmarks improve (including
> > xalancbmk by 11% and x264_r by 27%), but cactuBSSN_r has the 3% regression and
> > fotonik3d_r also has a new 3% regression.
> > 
> > Given that many more programs use floating point constants than vector
> > constants (66,000 XXSPLTID's created vs. 5,000 XXSPLTIW's), I figure to push
> > the XXSPLTIDP now, and try to figure out the differences before submitting the
> > XXSPLTIW patch.
> 
> It would be interesting to figure out a pattern behind the regressions :-)

Definately.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797


More information about the Gcc-patches mailing list