On Tue, 2017-05-09 at 16:03 -0500, Segher Boessenkool wrote:
> On Tue, May 09, 2017 at 02:33:00PM -0500, Steven Munroe wrote:
> > On Tue, 2017-05-09 at 12:23 -0500, Segher Boessenkool wrote:
> > > 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.
>
> That is just for the testsuite; I meant what happens if a user tries
> to use it with an older target (or BE, or 32-bit)? Is there a useful,
> obvious error message?
>
So looking at the X86 headers, their current practice falls into two two
areas.
1) guard 64-bit dependent intrinsic functions with:
#ifdef __x86_64__
#endif
But they do not provide any warnings. I assume that attempting to use an
intrinsic of this class would result in an implicit function declaration
and a link-time failure.
2) guard architecture level dependent intrinsic header content with:
#ifndef __AVX__
#pragma GCC push_options
#pragma GCC target("avx")
#define __DISABLE_AVX__
#endif /* __AVX__ */
...
#ifdef __DISABLE_AVX__
#undef __DISABLE_AVX__
#pragma GCC pop_options
#endif /* __DISABLE_AVX__ */
So they don't many any attempt to prevent them from using a specific
header. If the compiler version does not support the "GCC target" I
assume that specific did not exist in that version.
If GCC does support that target then the '#pragma GCC target("avx")'
will enable code generation, but the user might get a SIGILL if the
hardware they have does not support those instructions.
In the BMI headers I already guard with:
#ifdef __PPC64__
#endif
This means that like x86_64, attempting to use _pext_u64 on a 32-bit
compiler will result in an implicit function declaration and cause a
linker error.
This is sufficient for most of BMI and BMI2 (registers only / endian
agnostic). But this does not address the larger issues (for SSE/SSE2+)
which needing VXS implementation or restricting to LE.
So should I check for:
#ifdef __VSX__
#endif
or
#ifdef __POWER8_VECTOR__
or
#ifdef _ARCH_PWR8
and perhaps:
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
as well to enforce this.
And are you suggesting I add an #else clause with #warning or #error? Or
is the implicit function and link failure sufficient?
> > 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.
>
> Right.
>
> > 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.
>
> Agreed as well.
>
> > I don't plan to spend effort on supporting Intel intrinsic functions on
> > older PowerPC machines (before power8) or BE.
>
> Just make sure if anyone tries anyway, there is a clear error message
> that tells them not to.
>
>
> Segher
>
