[PATCH v4 08/12] math: Add math-use-builtinds-fmax.h
Adhemerval Zanella
adhemerval.zanella@linaro.org
Tue Dec 7 13:21:40 GMT 2021
On 06/12/2021 18:11, Joseph Myers wrote:
> On Thu, 2 Dec 2021, Adhemerval Zanella via Libc-alpha wrote:
>
>> +#if __HAVE_FLOAT128
>> +# define USE_BUILTIN_F128 , _Float128 : USE_FMAXF128_BUILTIN
>> +# define BUILTIN_F128 , _Float128 :__builtin_fmaxf128
>> +#else
>> +# define USE_BUILTIN_F128
>> +# define BUILTIN_F128
>> +#endif
>> +
>> +#define USE_BUILTIN(X, Y) \
>> + _Generic((X), \
>> + float : USE_FMAXF_BUILTIN, \
>> + double : USE_FMAX_BUILTIN, \
>> + long double : USE_FMAXL_BUILTIN \
>> + USE_BUILTIN_F128)
>> +
>> +#define BUILTIN(X, Y) \
>> + _Generic((X), \
>> + float : __builtin_fmaxf, \
>> + double : __builtin_fmax, \
>> + long double : __builtin_fmaxl \
>> + BUILTIN_F128) \
>> + (X, Y)
>
> You should not hardcode cases for different types in type-generic
> templates. This would fail if we add support for _Float16 functions in
> future, for example.
>
> Use M_SUF to call built-in functions (possibly via defining M_FMAX in
> math-type-macros.h, similar to the other M_* macros there.
>
> Do something similar for USE_*_BUILTIN (I suggest defining M_USE_BUILTIN
> in the per-type headers used by math-type-macros.h, so you can then call
> M_USE_BUILTIN (FMAX).
Indeed it is cleaner, I don't see the need of just M_FMAX.
>
> You'll probably need to use #if with the M_USE_BUILTIN call (which should
> be OK after the above changes), because GCC only added __builtin_fmaxfN
> functions in commit ee5fd23a481f510528e00f4c988ed0e6a71218c2 (GCC 8 and
> later) but older GCC versions are supported for building for some
> architectures with _Float128 support, and if __builtin_fmaxf128 gets
> referenced inside if (0) with older GCC it would be an undeclared
> identifier.
>
Right, but currently we use declare_mgen_alias for fmax/fmin, so I am not
sure it we really need to take care if __builtin_fmaxfN support.
For _Float128 I will need to check if this does incur in any issue, I
am currently building some older gcc toolchain to check it.
More information about the Libc-alpha
mailing list