On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
> TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided in the commit message).
> + if ((mode == TYPE_MODE (float_type_node))
> + || (mode == TYPE_MODE (double_type_node))
> + || (mode == TYPE_MODE (long_double_type_node)))
> + {
> + char val_name[64];
> + char fname[8] = "";
> + if (mode == TYPE_MODE (float_type_node))
> + memcpy (fname, "FLT", 4);
> + else if (mode == TYPE_MODE (double_type_node))
> + memcpy (fname, "DBL", 4);
> + else if (mode == TYPE_MODE (long_double_type_node))
> + memcpy (fname, "LDBL", 5);
This logic being used to generate EPSILON, MAX and MIN macros only handles
modes that match float, double or long double (so won't define the macros
for a mode that only matches another type such as _Float128, for example).
Earlier in the same function, there is existing code to define
__LIBGCC_%s_FUNC_EXT__. That code has to do something similar, to
determine the matching type for a mode - but it also handles _FloatN /
_FloatNx types, and has an assertion at the end that some matching type
was found.
Rather than having this code which handles a more limited set of types, I
think the __LIBGCC_%s_FUNC_EXT__ code should be extended, so that as well
as computing a function suffix it also computes a prefix such as FLT, DBL,
FLT128 or FLT64X. Then all supported floating-point modes can get these
three LIBGCC macros defined, rather than just those matching float, double
or long double.
> #elif defined(L_mulxc3) || defined(L_divxc3)
> # define MTYPE XFtype
> # define CTYPE XCtype
> # define MODE xc
> # define CEXT __LIBGCC_XF_FUNC_EXT__
> # define NOTRUNC (!__LIBGCC_XF_EXCESS_PRECISION__)
> +# define RBIG ((__LIBGCC_XF_MAX__)/2)
> +# define RMIN (__LIBGCC_XF_MIN__)
> +# define RMIN2 (__LIBGCC_DF_EPSILON__)
> +# define RMINSCAL (1/__LIBGCC_DF_EPSILON__)
> +# define RMAX2 ((RBIG)*(RMIN2))
I'd then expect __LIBGCC_XF_EPSILON__ to be used for XFmode in place of
__LIBGCC_DF_EPSILON__ unless there is some good reason to use the latter
(which would need a comment to explain it if so).
> #elif defined(L_multc3) || defined(L_divtc3)
> # define MTYPE TFtype
> # define CTYPE TCtype
> # define MODE tc
> # define CEXT __LIBGCC_TF_FUNC_EXT__
> # define NOTRUNC (!__LIBGCC_TF_EXCESS_PRECISION__)
> +#if defined(__LIBGCC_TF_MIN__)
> +# define RBIG ((__LIBGCC_TF_MAX__)/2)
> +# define RMIN (__LIBGCC_TF_MIN__)
> +#else
> +# define RBIG ((__LIBGCC_XF_MAX__)/2)
> +# define RMIN (__LIBGCC_XF_MIN__)
> +#endif
> +# define RMIN2 (__LIBGCC_DF_EPSILON__)
> +# define RMINSCAL (1/__LIBGCC_DF_EPSILON__)
And, likewise, with the suggested changes to c-cppbuiltin.c this code can
use __LIBGCC_TF_MAX__, __LIBGCC_TF_MIN__ and __LIBGCC_TF_EPSILON__
unconditionally, without ever needing to use XF or DF macros. (If you
want to use a different EPSILON value in the case where TFmode is IBM long
double because of LDBL_EPSILON being too small in that case, condition
that on __LIBGCC_TF_MANT_DIG__ == 106, and use ((TFtype) 0x1p-106) in
place of __LIBGCC_TF_EPSILON__ in that case.)
--
Joseph S. Myers
[email protected]
