On Thu, Dec 31, 2015 at 08:29:58PM +0000, Joseph Myers wrote:
> On Tue, 29 Dec 2015, Michael Meissner wrote:
>
> > +/* __eqkf2 returns 0 if equal, or 1 if not equal or NaN. */
> > +CMPtype
> > +__eqkf2_hw (TFtype a, TFtype b)
> > +{
> > + return (__builtin_isunordered (a, b) || (a != b)) ? 1 : 0;
>
> This is more complicated than necessary. "return a != b;" will suffice.
Ok. I will change this.
> > +/* __gekf2 returns -1 if a < b, 0 if a == b, +1 if a > b, or -2 if NaN. */
> > +CMPtype
> > +__gekf2_hw (TFtype a, TFtype b)
> > +{
> > + if (__builtin_isunordered (a, b))
> > + return -2;
> > +
> > + else if (a < b)
> > + return -1;
>
> The __builtin_isunordered check should come after the < check, so that the
> "invalid" exception gets raised for quiet NaN arguments.
>
> > +/* __lekf2 returns -1 if a < b, 0 if a == b, +1 if a > b, or +2 if NaN. */
> > +CMPtype
> > +__lekf2_hw (TFtype a, TFtype b)
> > +{
> > + if (__builtin_isunordered (a, b))
> > + return 2;
> > +
> > + else if (a < b)
> > + return -1;
>
> Likewise.
Ok. I will change these.
> > + char *p = (char *) getauxval (AT_PLATFORM);
>
> glibc deliberately exports __getauxval at a public symbol version, so you
> can do this in a namespace-clean way.
Ok. I will change this. The getauxval call by the way is only a temporary
measure until the support for __builtin_cpu_supports is added to the PowerPC.
> > +CMPtype __eqkf2 (TFtype, TFtype)
> > + __attribute__ ((__ifunc__ ("__eqkf2_resolve")));
> > +
> > +CMPtype __gekf2 (TFtype, TFtype)
> > + __attribute__ ((__ifunc__ ("__gekf2_resolve")));
> > +
> > +CMPtype __lekf2 (TFtype, TFtype)
> > + __attribute__ ((__ifunc__ ("__lekf2_resolve")));
>
> Don't you need to arrange __nekf2, __gtkf2, __ltkf2 aliases to these
> resolvers (the semantics mean they don't need to be separate functions,
> but the entry points need to be there given the optabs the back end sets
> up)?
Because of default conversions we cannot allow the normal optab mechanism to be
used for IEEE 128-bit floating point emulation. This is due to the fact that
if you have a __float128 comparison, the compiler will see if a larger type can
do the comparison, and in this case, the larger type is TFmode (i.e. IBM
extended double using the current defaults).
Instead rs6000_generate_compare generates the calls, and it does not use
the alternate names. I can easily put in the resolver calls as well for the
alternate names just in case somebody hand crafts a call to __nekf3.
>
> > +#ifdef _ARCH_PPC64
> > +TItype_ppc __fixkfti (TFtype)
> > + __attribute__ ((__ifunc__ ("__fixkfti_resolve")));
> > +
> > +UTItype_ppc __fixunskfti (TFtype)
> > + __attribute__ ((__ifunc__ ("__fixunskfti_resolve")));
> > +
> > +TFtype __floattikf (TItype_ppc)
> > + __attribute__ ((__ifunc__ ("__floattikf_resolve")));
> > +
> > +TFtype __floatuntikf (UTItype_ppc)
> > + __attribute__ ((__ifunc__ ("__floatuntikf_resolve")));
> > +#endif
>
> I don't see the point of using ifuncs that just always return the software
> version. You might as well just give the software version the appropriate
> function name directly, and add ifuncs later if adding a version using
> hardware arithmetic (e.g. doing something like the libgcc2.c functions
> with hardware conversions to/from DImode).
I'll think about it. At some point, I was hoping to have implementations for
ISA 3.0. However, there is not an ISA 3.0 instruction that converts from
128-bit integer to 128-bit floating point or vice versa.
>
> > +#define ISA_BIT(x) (1 << (63 - x))
>
> As far as I can see, my previous comment still applies: this part of the
> sfp-machine.h changes needs to be under some appropriate conditional so
> that it only applies when building the KFmode functions, not for 32-bit
> soft-float / e500 libgcc builds.
Agreed. I will fix this.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
