qiurui
/
glibc
mirror of git://sourceware.org/git/glibc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
glibc/sysdeps/powerpc/powerpc64/le/fpu/multiarch/Makefile

348 lines
16 KiB
Makefile
Raw Normal View History

powerpc: Add multiarch sqrtf128 for ppc64le This patch creates ifunc for sqrtf128() to make use of new xssqrtqp instruction for POWER9 when --enable-multi-arch and --with-cpu=power8 options are used on power9 system. This is achieved by explicitly adding -mcpu=power9 flag for sqrtf128-power9.
2018-05-30 16:01:27 +00:00
ifeq ($(subdir),math)
powerpc: Add support for fmaf128() in hardware Adds a POWER9 version of fmaf128 that uses the xsmaddqp instruction. Co-authored-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2020-03-20 20:52:28 +00:00
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
#
# Only enable ifunc _Float128 support if the baseline cpu support
# is older than power9.
ifneq (yes,$(libc-submachine-power9))
do_f128_multiarch = yes
endif
#
# This is an ugly, but contained, mechanism to provide hardware optimized
# _Float128 and ldouble == ieee128 optimized routines for P9 and beyond
# hardware. At a very high level, we rely on ASM renames, and rarely
# macro renames to build two sets of _Float128 ABI, one with _power8 (the
# baseline powerpc64le cpu) and _power9 (the first powerpc64le cpu to introduce
# hardware support for _Float128).
#
# At a high level, we compile 3 files for each object file.
# 1. The baseline soft-float128, unsuffixed objects $(object).$(sfx)
# The symbols contained in these files is suffixed by _power8.
# 2. The hard-float128, power9, suffixed objects $(object)-power9.$(sfx).
# The symbols contained in these files is suffixed by _power9.
# 3. The IFUNC wrapper object to export ABI, $(object)-ifunc.$(sfx)
# This glues the above together and implements the ABI.
#
# 2 & 3 are automatically generated by Makefile rule. Placing the exported
# ABI into a separate file allows reuse of existing aliasing macros
# with minimal hassle.
#
#
# If the float128 ABI is expanded, and a new ifunc wrappers are desired,
# the following lists how to map new symbols from the shared headers into
# their local overrides here:
#
# float128_private.h
#
# is used to rename the ldouble == ieee128 object files. This takes
# it a step further and redirects symbols to a local name. This supports
# nearly all files in sysdeps/ieee754/float128, but not all _Float128
# objects. However, this is only meant to be used internally to support
# compilation of ldbl-128 into float128.
#
# math-type-macros-float128.h
#
# renames symbols which are generated via shared templated in math/.
#
# math_private.h
#
# provides internal declarations for common macros and functions which
# are called from within libm. Note, float128_private.h duplicates
# some of these declarations as these headers are generally not included
# in the same translation unit.
#
# The above is supported by several header files as described below:
#
# float128-ifunc.h
#
# provides support for generating the IFUNC objects in part 3 above.
# This header is only included with wrapper functions.
#
# float128-ifunc-macros.h
#
# disables all first-order float128 aliasing macros used in libm,
# and libm wrappers around libc-symbols.h.
#
# float128-ifunc-redirect-macros.h
#
# provides macros which implement the appending of the suffix to
# symbols what have been selected.
#
# float128-ifunc-redirects.h
#
# provides ASM redirects for symbols which are redirected in the
# private copy of math.h used by glibc, but not declared by math_private.h
#
# float128-ifunc-redirects-mp.h
#
# provides ASM redirects which are used by math_private.h (the -mp suffix)
# and the interposer float128_private.h discussed late.
#
# Notably, this enforces a slightly different mechanism for machine specific
# overrides. Optimizations for all targets must all be reachable from the same
# file. See the history to fmaf128 or sqrtf128 to understand how this looks
# in practice.
#
ifeq ($(do_f128_multiarch),yes)
powerpc64le: Use ifunc for _Float128 functions also in libc This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
2021-03-31 12:17:24 +00:00
f128-ifunc-calls = s_modff128 s_scalbnf128 s_frexpf128 s_ldexpf128
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
gen-libm-f128-ifunc-routines = \
e_acosf128 e_acoshf128 e_asinf128 e_atan2f128 e_atanhf128 e_coshf128 \
e_expf128 e_fmodf128 e_hypotf128 e_j0f128 e_j1f128 e_jnf128 \
e_lgammaf128_r e_logf128 e_log10f128 e_powf128 e_remainderf128 \
e_sinhf128 e_sqrtf128 e_gammaf128_r e_ilogbf128 k_tanf128 s_asinhf128 \
Implement C23 exp2m1, exp10m1 C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
2024-06-17 16:31:49 +00:00
s_atanf128 s_cbrtf128 s_ceilf128 s_cosf128 s_erff128 s_exp10m1f128 \
s_exp2m1f128 s_expm1f128 \
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
s_fabsf128 s_floorf128 s_log1pf128 s_logbf128 \
s_rintf128 s_scalblnf128 s_sinf128 s_tanf128 \
s_tanhf128 s_truncf128 s_remquof128 e_log2f128 \
s_roundf128 s_nearbyintf128 s_sincosf128 s_fmaf128 s_lrintf128 \
s_llrintf128 s_lroundf128 s_llroundf128 e_exp10f128 \
powerpc64le: Use ifunc for _Float128 functions also in libc This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
2021-03-31 12:17:24 +00:00
$(f128-ifunc-calls) $(f128-ifunc-calls:s_%=m_%) x2y2m1f128 \
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
gamma_productf128 lgamma_negf128 lgamma_productf128 s_roundevenf128 \
cargf128 conjf128 cimagf128 crealf128 cabsf128 e_scalbf128 s_cacosf128 \
s_cacoshf128 s_ccosf128 s_ccoshf128 s_casinf128 s_csinf128 \
s_casinhf128 k_casinhf128 s_csinhf128 k_casinhf128 s_csinhf128 \
s_catanhf128 s_catanf128 s_ctanf128 s_ctanhf128 s_cexpf128 s_clogf128 \
s_cprojf128 s_csqrtf128 s_cpowf128 s_clog10f128 s_fdimf128 \
s_fmaxf128 s_fminf128 w_ilogbf128 w_llogbf128 \
w_log1pf128 w_scalblnf128 w_acosf128 \
w_acoshf128 w_asinf128 w_atan2f128 w_atanhf128 w_coshf128 w_exp10f128 \
w_exp2f128 w_fmodf128 w_hypotf128 w_j0f128 w_j1f128 w_jnf128 \
w_logf128 w_log10f128 w_log2f128 w_powf128 w_remainderf128 \
w_scalbf128 w_sinhf128 w_sqrtf128 w_tgammaf128 w_lgammaf128 \
w_lgammaf128_r w_expf128 e_exp2f128 \
k_sinf128 k_cosf128 k_sincosf128 e_rem_pio2f128
f128-march-routines-p9 = $(addsuffix -power9,$(gen-libm-f128-ifunc-routines))
f128-march-routines-ifunc = $(addsuffix -ifunc,$(gen-libm-f128-ifunc-routines))
f128-march-routines = $(f128-march-routines-p9) $(f128-march-routines-ifunc)
f128-march-cpus = power9
powerpc64le: Use ifunc for _Float128 functions also in libc This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
2021-03-31 12:17:24 +00:00
f128-march-calls-p9 = $(addsuffix -power9,$(f128-ifunc-calls))
f128-march-calls-ifunc = $(addsuffix -ifunc,$(f128-ifunc-calls))
f128-march-calls = $(f128-march-calls-p9) $(f128-march-calls-ifunc)
calls += $(f128-march-calls)
libm-routines += $(filter-out $(f128-march-calls), $(f128-march-routines))
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
generated += $(f128-march-routines)
CFLAGS-float128-ifunc.c += $(type-float128-CFLAGS) $(no-gnu-attribute-CFLAGS)
# Copy special CFLAGS for some functions
Disable use of -fsignaling-nans if compiler does not support it Reviewed-by: Fangrui Song <maskray@google.com>
2022-03-07 18:09:53 +00:00
CFLAGS-s_modff128-power9.c += $(config-cflags-signaling-nans)
CFLAGS-m_modff128-power9.c += $(config-cflags-signaling-nans)
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
# Generate ifunc wrapper files and target specific wrappers around
# each routine above. Note, m_%.c files are fixed up to include
# s_%.c files. This is an artifact of the makefile rules which allow
# some files to be compiled for libc and libm.
powerpc64le: Use ifunc for _Float128 functions also in libc This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
2021-03-31 12:17:24 +00:00
$(objpfx)gen-float128-ifuncs.stmp: \
Makefile $(..)sysdeps/powerpc/powerpc64/le/fpu/multiarch/Makefile
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
$(make-target-directory)
for gcall in $(gen-libm-f128-ifunc-routines); do \
ifile="$${gcall}"; \
if [ $${gcall##m_} != $${gcall} ]; then \
ifile="s_$${gcall##m_}"; \
fi; \
for cpu in $(f128-march-cpus); do \
file=$(objpfx)$${gcall}-$${cpu}.c; \
{ \
echo "#include <$${ifile}.c>"; \
} > $${file}; \
done; \
name="$${gcall##?_}"; \
pfx="$${gcall%%_*}"; \
R=""; \
r=""; \
if [ $${gcall##m_} != $${gcall} ]; then \
pfx="s"; \
fi; \
if [ $${#pfx} != 1 ]; then \
pfx=""; \
else \
pfx="_$${pfx}"; \
fi; \
if [ $${name%%_r} != $${name} ]; then \
R="_R"; \
r="_r"; \
name="$${name%%_r}"; \
fi; \
name="$${name%%f128}"; \
decl="DECL_ALIAS$${pfx}_$${name}$${r}"; \
compat="GEN_COMPAT$${pfx}_$${name}$${r}"; \
declc="DECL_ALIAS$${R}$${pfx}"; \
{ \
echo "#include <float128-ifunc.h>"; \
echo "#ifndef $${decl}"; \
echo "# define $${decl}(f) $${declc} (f)"; \
echo "#endif"; \
echo "#ifndef $${compat}"; \
echo "# define $${compat}(f)"; \
echo "#endif"; \
echo "$${decl} ($${name});"; \
echo "$${compat} ($${name});"; \
} > $(objpfx)$${gcall}-ifunc.c; \
done; \
echo > $(@)
powerpc64le: Use ifunc for _Float128 functions also in libc This fixes missing definition of math functions in libc in a static link that are no longer built for libm after commit 4898d9712b ("Avoid adding duplicated symbols into static libraries").
2021-03-31 12:17:24 +00:00
$(foreach f,$(f128-march-routines),$(objpfx)$(f).c): \
$(objpfx)gen-float128-ifuncs.stmp $(objpfx)gen-libm-templates.stmp
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
enable-f128-ifunc-CFLAGS = -D_F128_ENABLE_IFUNC $(no-gnu-attributes-CFLAGS) $(type-float128-CFLAGS)
# Enable IFUNC on baseline (power8) implementations
include $(o-iterator)
define o-iterator-doit
$(foreach f,$(gen-libm-f128-ifunc-routines),$(objpfx)$(f)$(o)): sysdep-CFLAGS += -D_F128_ENABLE_IFUNC
endef
object-suffixes-left := $(all-object-suffixes)
include $(o-iterator)
# Likewise, but for power9.
include $(o-iterator)
define o-iterator-doit
$(foreach f,$(f128-march-routines-p9),$(objpfx)$(f)$(o)): sysdep-CFLAGS += $$(enable-f128-ifunc-CFLAGS) -mcpu=power9
endef
object-suffixes-left := $(all-object-suffixes)
include $(o-iterator)
powerpc: Add multiarch sqrtf128 for ppc64le This patch creates ifunc for sqrtf128() to make use of new xssqrtqp instruction for POWER9 when --enable-multi-arch and --with-cpu=power8 options are used on power9 system. This is achieved by explicitly adding -mcpu=power9 flag for sqrtf128-power9.
2018-05-30 16:01:27 +00:00
Fix build with GCC 13 _FloatN, _FloatNx built-in functions GCC 13 has added more _FloatN and _FloatNx versions of existing <math.h> and <complex.h> built-in functions, for use in libstdc++-v3. This breaks the glibc build because of how those functions are defined as aliases to functions with the same ABI but different types. Add appropriate -fno-builtin-* options for compiling relevant files, as already done for the case of long double functions aliasing double ones and based on the list of files used there. I fixed some mistakes in that list of double files that I noticed while implementing this fix, but there may well be more such (harmless) cases, in this list or the new one (files that don't actually exist or don't define the named functions as aliases so don't need the options). I did try to exclude cases where glibc doesn't define certain functions for _FloatN or _FloatNx types at all from the new uses of -fno-builtin-* options. As with the options for double files (see the commit message for commit 49348beafe9ba150c9bd48595b3f372299bddbb0, "Fix build with GCC 10 when long double = double."), it's deliberate that the options are used even if GCC currently doesn't have a built-in version of a given functions, so providing some level of future-proofing against more such built-in functions being added in future. Tested with build-many-glibcs.py for aarch64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu (compilers and glibcs builds) with GCC mainline.
2022-10-31 23:20:08 +00:00
CFLAGS-w_acosf128-ifunc.c += -fno-builtin-acosf64x
CFLAGS-w_acoshf128-ifunc.c += -fno-builtin-acoshf64x
CFLAGS-w_asinf128-ifunc.c += -fno-builtin-asinf64x
CFLAGS-s_asinhf128-ifunc.c += -fno-builtin-asinhf64x
CFLAGS-s_atanf128-ifunc.c += -fno-builtin-atanf64x
CFLAGS-w_atan2f128-ifunc.c += -fno-builtin-atan2f64x
CFLAGS-w_atanhf128-ifunc.c += -fno-builtin-atanhf64x
CFLAGS-s_cabsf128-ifunc.c += -fno-builtin-cabsf64x
CFLAGS-s_cacosf128-ifunc.c += -fno-builtin-cacosf64x
CFLAGS-s_cacoshf128-ifunc.c += -fno-builtin-cacoshf64x
CFLAGS-s_canonicalizef128-ifunc.c += -fno-builtin-canonicalizef64x
CFLAGS-s_cargf128-ifunc.c += -fno-builtin-cargf64x
CFLAGS-s_casinf128-ifunc.c += -fno-builtin-casinf64x
CFLAGS-s_casinhf128-ifunc.c += -fno-builtin-casinhf64x
CFLAGS-s_catanf128-ifunc.c += -fno-builtin-catanf64x
CFLAGS-s_catanhf128-ifunc.c += -fno-builtin-catanhf64x
CFLAGS-s_cbrtf128-ifunc.c += -fno-builtin-cbrtf64x
CFLAGS-s_ccosf128-ifunc.c += -fno-builtin-ccosf64x
CFLAGS-s_ccoshf128-ifunc.c += -fno-builtin-ccoshf64x
CFLAGS-s_ceilf128-ifunc.c += -fno-builtin-ceilf64x
CFLAGS-s_cexpf128-ifunc.c += -fno-builtin-cexpf64x
CFLAGS-s_cimagf128-ifunc.c += -fno-builtin-cimagf64x
CFLAGS-s_clogf128-ifunc.c += -fno-builtin-clogf64x
CFLAGS-s_clog10f128-ifunc.c += -fno-builtin-clog10f64x
CFLAGS-s_conjf128-ifunc.c += -fno-builtin-conjf64x
CFLAGS-s_copysignf128-ifunc.c += -fno-builtin-copysignf64x
CFLAGS-s_cosf128-ifunc.c += -fno-builtin-cosf64x
CFLAGS-w_coshf128-ifunc.c += -fno-builtin-coshf64x
CFLAGS-s_cpowf128-ifunc.c += -fno-builtin-cpowf64x
CFLAGS-s_cprojf128-ifunc.c += -fno-builtin-cprojf64x
CFLAGS-s_crealf128-ifunc.c += -fno-builtin-crealf64x
CFLAGS-s_csinf128-ifunc.c += -fno-builtin-csinf64x
CFLAGS-s_csinhf128-ifunc.c += -fno-builtin-csinhf64x
CFLAGS-s_csqrtf128-ifunc.c += -fno-builtin-csqrtf64x
CFLAGS-s_ctanf128-ifunc.c += -fno-builtin-ctanf64x
CFLAGS-s_ctanhf128-ifunc.c += -fno-builtin-ctanhf64x
CFLAGS-s_daddf128-ifunc.c += -fno-builtin-f64addf64x
CFLAGS-s_ddivf128-ifunc.c += -fno-builtin-f64divf64x
CFLAGS-s_dfmaf128-ifunc.c += -fno-builtin-f64fmaf64x
CFLAGS-s_dmulf128-ifunc.c += -fno-builtin-f64mulf64x
CFLAGS-s_dsqrtf128-ifunc.c += -fno-builtin-f64sqrtf64x
CFLAGS-s_dsubf128-ifunc.c += -fno-builtin-f64subf64x
CFLAGS-s_erff128-ifunc.c += -fno-builtin-erff64x
CFLAGS-s_erfcf128-ifunc.c += -fno-builtin-erfcf64x
CFLAGS-e_expf128-ifunc.c += -fno-builtin-expf64x
CFLAGS-w_exp10f128-ifunc.c += -fno-builtin-exp10f64x
Implement C23 exp2m1, exp10m1 C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
2024-06-17 16:31:49 +00:00
CFLAGS-s_exp10m1f128-ifunc.c += -fno-builtin-exp10m1f64x
Fix build with GCC 13 _FloatN, _FloatNx built-in functions GCC 13 has added more _FloatN and _FloatNx versions of existing <math.h> and <complex.h> built-in functions, for use in libstdc++-v3. This breaks the glibc build because of how those functions are defined as aliases to functions with the same ABI but different types. Add appropriate -fno-builtin-* options for compiling relevant files, as already done for the case of long double functions aliasing double ones and based on the list of files used there. I fixed some mistakes in that list of double files that I noticed while implementing this fix, but there may well be more such (harmless) cases, in this list or the new one (files that don't actually exist or don't define the named functions as aliases so don't need the options). I did try to exclude cases where glibc doesn't define certain functions for _FloatN or _FloatNx types at all from the new uses of -fno-builtin-* options. As with the options for double files (see the commit message for commit 49348beafe9ba150c9bd48595b3f372299bddbb0, "Fix build with GCC 10 when long double = double."), it's deliberate that the options are used even if GCC currently doesn't have a built-in version of a given functions, so providing some level of future-proofing against more such built-in functions being added in future. Tested with build-many-glibcs.py for aarch64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu (compilers and glibcs builds) with GCC mainline.
2022-10-31 23:20:08 +00:00
CFLAGS-e_exp2f128-ifunc.c += -fno-builtin-exp2f64x
Implement C23 exp2m1, exp10m1 C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
2024-06-17 16:31:49 +00:00
CFLAGS-s_exp2m1f128-ifunc.c += -fno-builtin-exp2m1f64x
Fix build with GCC 13 _FloatN, _FloatNx built-in functions GCC 13 has added more _FloatN and _FloatNx versions of existing <math.h> and <complex.h> built-in functions, for use in libstdc++-v3. This breaks the glibc build because of how those functions are defined as aliases to functions with the same ABI but different types. Add appropriate -fno-builtin-* options for compiling relevant files, as already done for the case of long double functions aliasing double ones and based on the list of files used there. I fixed some mistakes in that list of double files that I noticed while implementing this fix, but there may well be more such (harmless) cases, in this list or the new one (files that don't actually exist or don't define the named functions as aliases so don't need the options). I did try to exclude cases where glibc doesn't define certain functions for _FloatN or _FloatNx types at all from the new uses of -fno-builtin-* options. As with the options for double files (see the commit message for commit 49348beafe9ba150c9bd48595b3f372299bddbb0, "Fix build with GCC 10 when long double = double."), it's deliberate that the options are used even if GCC currently doesn't have a built-in version of a given functions, so providing some level of future-proofing against more such built-in functions being added in future. Tested with build-many-glibcs.py for aarch64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu (compilers and glibcs builds) with GCC mainline.
2022-10-31 23:20:08 +00:00
CFLAGS-s_expm1f128-ifunc.c += -fno-builtin-expm1f64x
CFLAGS-s_fabsf128-ifunc.c += -fno-builtin-fabsf64x
CFLAGS-s_faddf128-ifunc.c += -fno-builtin-f32addf64x
CFLAGS-s_fdimf128-ifunc.c += -fno-builtin-fdimf64x
CFLAGS-s_fdivf128-ifunc.c += -fno-builtin-f32divf64x
CFLAGS-s_ffmaf128-ifunc.c += -fno-builtin-f32fmaf64x
CFLAGS-s_floorf128-ifunc.c += -fno-builtin-floorf64x
CFLAGS-s_fmaf128-ifunc.c += -fno-builtin-fmaf64x
CFLAGS-s_fmaxf128-ifunc.c += -fno-builtin-fmaxf64x
CFLAGS-s_fmaximumf128-ifunc.c += -fno-builtin-fmaximumf64x
CFLAGS-s_fmaximum_magf128-ifunc.c += -fno-builtin-fmaximum_magf64x
CFLAGS-s_fmaximum_mag_numf128-ifunc.c += -fno-builtin-fmaximum_mag_numf64x
CFLAGS-s_fmaximum_numf128-ifunc.c += -fno-builtin-fmaximum_numf64x
CFLAGS-s_fmaxmagf128-ifunc.c += -fno-builtin-fmaxmagf64x
CFLAGS-s_fminf128-ifunc.c += -fno-builtin-fminf64x
CFLAGS-s_fminimumf128-ifunc.c += -fno-builtin-fminimumf64x
CFLAGS-s_fminimum_magf128-ifunc.c += -fno-builtin-fminimum_magf64x
CFLAGS-s_fminimum_mag_numf128-ifunc.c += -fno-builtin-fminimum_mag_numf64x
CFLAGS-s_fminimum_numf128-ifunc.c += -fno-builtin-fminimum_numf64x
CFLAGS-s_fminmagf128-ifunc.c += -fno-builtin-fminmagf64x
CFLAGS-w_fmodf128-ifunc.c += -fno-builtin-fmodf64x
CFLAGS-s_fmulf128-ifunc.c += -fno-builtin-f32mulf64x
CFLAGS-s_frexpf128-ifunc.c += -fno-builtin-frexpf64x
CFLAGS-s_fromfpf128-ifunc.c += -fno-builtin-fromfpf64x
CFLAGS-s_fromfpxf128-ifunc.c += -fno-builtin-fromfpxf64x
CFLAGS-s_fsqrtf128-ifunc.c += -fno-builtin-f32sqrtf64x
CFLAGS-s_fsubf128-ifunc.c += -fno-builtin-f32subf64x
CFLAGS-s_getpayloadf128-ifunc.c += -fno-builtin-getpayloadf64x
CFLAGS-w_hypotf128-ifunc.c += -fno-builtin-hypotf64x
CFLAGS-w_ilogbf128-ifunc.c += -fno-builtin-ilogbf64x
CFLAGS-w_j0f128-ifunc.c += -fno-builtin-j0f64x
CFLAGS-w_j1f128-ifunc.c += -fno-builtin-j1f64x
CFLAGS-w_jnf128-ifunc.c += -fno-builtin-jnf64x
CFLAGS-s_ldexpf128-ifunc.c += -fno-builtin-ldexpf64x
CFLAGS-w_lgammaf128-ifunc.c += -fno-builtin-lgammaf64x
CFLAGS-w_lgammaf128_r-ifunc.c += -fno-builtin-lgammaf64x_r
CFLAGS-w_llogbf128-ifunc.c += -fno-builtin-llogbf64x
CFLAGS-s_llrintf128-ifunc.c += -fno-builtin-llrintf64x
CFLAGS-s_llroundf128-ifunc.c += -fno-builtin-llroundf64x
CFLAGS-e_logf128-ifunc.c += -fno-builtin-logf64x
CFLAGS-w_log10f128-ifunc.c += -fno-builtin-log10f64x
Implement C23 logp1 C23 adds various <math.h> function families originally defined in TS 18661-4. Add the logp1 functions (aliases for log1p functions - the name is intended to be more consistent with the new log2p1 and log10p1, where clearly it would have been very confusing to name those functions log21p and log101p). As aliases rather than new functions, the content of this patch is somewhat different from those actually adding new functions. Tests are shared with log1p, so this patch *does* mechanically update all affected libm-test-ulps files to expect the same errors for both functions. The vector versions of log1p on aarch64 and x86_64 are *not* updated to have logp1 aliases (and thus there are no corresponding header, tests, abilist or ulps changes for vector functions either). It would be reasonable for such vector aliases and corresponding changes to other files to be made separately. For now, the log1p tests instead avoid testing logp1 in the vector case (a Makefile change is needed to avoid problems with grep, used in generating the .c files for vector function tests, matching more than one ALL_RM_TEST line in a file testing multiple functions with the same inputs, when it assumes that the .inc file only has a single such line). Tested for x86_64 and x86, and with build-many-glibcs.py.
2024-06-17 13:47:09 +00:00
CFLAGS-w_log1pf128-ifunc.c += -fno-builtin-log1pf64x -fno-builtin-logp1f64x
Fix build with GCC 13 _FloatN, _FloatNx built-in functions GCC 13 has added more _FloatN and _FloatNx versions of existing <math.h> and <complex.h> built-in functions, for use in libstdc++-v3. This breaks the glibc build because of how those functions are defined as aliases to functions with the same ABI but different types. Add appropriate -fno-builtin-* options for compiling relevant files, as already done for the case of long double functions aliasing double ones and based on the list of files used there. I fixed some mistakes in that list of double files that I noticed while implementing this fix, but there may well be more such (harmless) cases, in this list or the new one (files that don't actually exist or don't define the named functions as aliases so don't need the options). I did try to exclude cases where glibc doesn't define certain functions for _FloatN or _FloatNx types at all from the new uses of -fno-builtin-* options. As with the options for double files (see the commit message for commit 49348beafe9ba150c9bd48595b3f372299bddbb0, "Fix build with GCC 10 when long double = double."), it's deliberate that the options are used even if GCC currently doesn't have a built-in version of a given functions, so providing some level of future-proofing against more such built-in functions being added in future. Tested with build-many-glibcs.py for aarch64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu (compilers and glibcs builds) with GCC mainline.
2022-10-31 23:20:08 +00:00
CFLAGS-e_log2f128-ifunc.c += -fno-builtin-log2f64x
CFLAGS-s_logbf128-ifunc.c += -fno-builtin-logbf64x
CFLAGS-s_lrintf128-ifunc.c += -fno-builtin-lrintf64x
CFLAGS-s_lroundf128-ifunc.c += -fno-builtin-lroundf64x
CFLAGS-s_modff128-ifunc.c += -fno-builtin-modff64x
CFLAGS-s_nanf128-ifunc.c += -fno-builtin-nanf64x
CFLAGS-s_nearbyintf128-ifunc.c += -fno-builtin-nearbyintf64x
CFLAGS-s_nextafterf128-ifunc.c += -fno-builtin-nextafterf64x
CFLAGS-s_nextdownf128-ifunc.c += -fno-builtin-nextdownf64x
CFLAGS-s_nextupf128-ifunc.c += -fno-builtin-nextupf64x
CFLAGS-e_powf128-ifunc.c += -fno-builtin-powf64x
CFLAGS-w_remainderf128-ifunc.c += -fno-builtin-remainderf64x
CFLAGS-s_remquof128-ifunc.c += -fno-builtin-remquof64x
CFLAGS-s_rintf128-ifunc.c += -fno-builtin-rintf64x
CFLAGS-s_roundf128-ifunc.c += -fno-builtin-roundf64x
CFLAGS-s_roundevenf128-ifunc.c += -fno-builtin-roundevenf64x
CFLAGS-w_scalblnf128-ifunc.c += -fno-builtin-scalblnf64x
CFLAGS-s_scalbnf128-ifunc.c += -fno-builtin-scalbnf64x
CFLAGS-s_setpayloadf128-ifunc.c += -fno-builtin-setpayloadf64x
CFLAGS-s_setpayloadsigf128-ifunc.c += -fno-builtin-setpayloadsigf64x
CFLAGS-s_sinf128-ifunc.c += -fno-builtin-sinf64x
CFLAGS-s_sincosf128-ifunc.c += -fno-builtin-sincosf64x
CFLAGS-w_sinhf128-ifunc.c += -fno-builtin-sinhf64x
CFLAGS-w_sqrtf128-ifunc.c += -fno-builtin-sqrtf64x
CFLAGS-s_tanf128-ifunc.c += -fno-builtin-tanf64x
CFLAGS-s_tanhf128-ifunc.c += -fno-builtin-tanhf64x
CFLAGS-w_tgammaf128-ifunc.c += -fno-builtin-tgammaf64x
CFLAGS-s_totalorderf128-ifunc.c += -fno-builtin-totalorderf64x
CFLAGS-s_totalordermagf128-ifunc.c += -fno-builtin-totalordermagf64x
CFLAGS-s_truncf128-ifunc.c += -fno-builtin-truncf64x
CFLAGS-s_ufromfpf128-ifunc.c += -fno-builtin-ufromfpf64x
CFLAGS-s_ufromfpxf128-ifunc.c += -fno-builtin-ufromfpxf64x
CFLAGS-s_y0f128-ifunc.c += -fno-builtin-y0f64x
CFLAGS-s_y1f128-ifunc.c += -fno-builtin-y1f64x
CFLAGS-s_ynf128-ifunc.c += -fno-builtin-ynf64x
powerpc64le: ifunc select *f128 routines in multiarch mode Programatically generate simple wrappers for interesting libm *f128 objects. Selected functions are transcendental functions or those with trivial compiler builtins. This can result in a 2-3x speedup (e.g logf128 and expf128). A second set of implementation files are generated which include the first implementation encountered along the search path. This usually works, except when a wrapper is overriden and makefile search order slightly diverges from include order. Likewise, wrapper object files are created for each generated file. These hold the ifunc selection routines which export ABI. Next, several shared headers are intercepted to control renaming of asm function redirects are used first, and sometimes macro renames if the former is impractical. Notably, if the request machine supports hardware IEEE128 (i.e POWER9 and newer) this ifunc machinery is disabled. Likewise existing ifunc support for float128 is consolidated into this (e.g sqrtf128 and fmaf128). Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
2020-04-07 21:20:55 +00:00
endif # do_f128_multiarch
powerpc: Add log IFUNC multiarch support for POWER10 Checked on ppc64le built without --with-cpu, with --with-cpu=power9 and with --disable-multi-arch. Reviewed-by: Matheus Castanho <msc@linux.ibm.com>
2021-02-25 13:42:27 +00:00
libm-sysdep_routines += e_log-ppc64
ifeq ($(mcpu-power10), yes)
libm-sysdep_routines += e_log-power10
CFLAGS-e_log-power10.c += -mcpu=power10
endif
powerpc: Add multiarch sqrtf128 for ppc64le This patch creates ifunc for sqrtf128() to make use of new xssqrtqp instruction for POWER9 when --enable-multi-arch and --with-cpu=power8 options are used on power9 system. This is achieved by explicitly adding -mcpu=power9 flag for sqrtf128-power9.
2018-05-30 16:01:27 +00:00
endif