Re: [PATCH, rs6000] Add x86 instrinsic headers to GCC PPC64LE taget

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Tue, 2017-05-09 at 12:23 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, May 08, 2017 at 09:49:57AM -0500, Steven Munroe wrote:
> > Thus I would like to restrict this support to PowerPC
> > targets that support VMX/VSX and PowerISA-2.07 (power8) and later.
> 
> What happens if you run it on an older machine, or as BE or 32-bit,
> or with vectors disabled?
> 
Well I hope that I set the dg-require-effective-target correctly because
while some of these intrinsics might work on the BE or 32-bit machine,
most will not.

For example; many of the BMI intrinsic implementations depend on 64-bit
instructions and so I use { dg-require-effective-target lp64 }.  The
BMI2 intrinsic _pext exploits the Bit Permute Doubleword instruction.
There is no Bit Permute Word instruction. So for BMI2 I use
{ dg-require-effective-target powerpc_vsx_ok } as bpermd was introduced
in PowerISA 2.06 along with the Vector Scalar Extension facility.

The situation gets more complicated when we start looking at the
SSE/SSE2. These headers define many variants of load and store
instructions that are decidedly LE and many unaligned forms. While
powerpc64le handles this with ease, implementing LE semantics in BE mode
gets seriously tricky. I think it is better to avoid this and only
support these headers for LE.

And while some SSE instrinsics can be implemented with VMX instructions
all the SSE2 double float intrinsics require VSX. And some PowerISA 2.07
instructions simplify implementation if available. As power8 is also the
first supported powerpc64le system it seems the logical starting point
for most of this work. 

I don't plan to spend effort on supporting Intel intrinsic functions on
older PowerPC machines (before power8) or BE.

> > So I propose to submit a series of patches to implement the PowerPC64LE
> > equivalent of a useful subset of the x86 intrinsics. The final size and
> > usefulness of this effort is to be determined. The proposal is to
> > incrementally port intrinsic header files from the ./config/i386 tree to
> > the ./config/rs6000 tree. This naturally provides the same header
> > structure and intrinsic names which will simplify code porting.
> 
> Yeah.
> 
> I'd still like to see these headers moved into some subdir (both in
> the source tree and in the installed headers tree), to reduce clutter,
> but I understand it's not trivial to do.
> 
> > To get the ball rolling I include the BMI intrinsics ported to PowerPC
> > for review as they are reasonable size (31 intrinsic implementations).
> 
> This is okay for trunk.  Thanks!
> 
Thank you

> > --- gcc/config.gcc	(revision 247616)
> > +++ gcc/config.gcc	(working copy)
> > @@ -444,7 +444,7 @@ nvptx-*-*)
> >  	;;
> >  powerpc*-*-*)
> >  	cpu_type=rs6000
> > -	extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h
> > spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
> > +	extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h
> > spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h bmi2intrin.h
> > bmiintrin.h x86intrin.h"
> 
> (Your mail client wrapped this).
> 
> Write this on a separate line?  Like
>   extra_headers="${extra_headers} htmintrin.h htmxlintrin.h bmi2intrin.h"
> (You cannot use += here, pity).
> 
> 
> Segher
>