| Message ID | 20180511194045.7701-1-tuliom@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Move M_DECL_FUNC_R* to math-type-macros.h | expand |
On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > Thread-safe math functions (*_r) have a different naming scheme that > doesn't fit the M_SUF() / M_DECL_FUNC() mechanism. > Move the M_DECL_FUNC_R() implementation from w_lgamma_r_template.c to > math-type-macros.h in order to reuse these macros in other functions. lgamma_r is a pretty unique function and I don't see any likely other such functions (at all, whether or not they might be implemented with type-generic templates). So again, you'll need to explain more why this is useful (or if it's just intended as a cleanup, I think such a cleanup should make the _r an explicit macro argument so M_DECL_FUNC can be defined in terms of M_DECL_FUNC_R, just as libm_alias_float is defined in terms of libm_alias_float_r, etc., unless there's some reason that can't work).
Joseph Myers <joseph@codesourcery.com> writes: > On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > >> Thread-safe math functions (*_r) have a different naming scheme that >> doesn't fit the M_SUF() / M_DECL_FUNC() mechanism. >> Move the M_DECL_FUNC_R() implementation from w_lgamma_r_template.c to >> math-type-macros.h in order to reuse these macros in other functions. > > lgamma_r is a pretty unique function and I don't see any likely other such > functions (at all, whether or not they might be implemented with > type-generic templates). There is also gamma_r. Let me try to explain... > So again, you'll need to explain more why this > is useful (or if it's just intended as a cleanup, I think such a cleanup > should make the _r an explicit macro argument so M_DECL_FUNC can be > defined in terms of M_DECL_FUNC_R, just as libm_alias_float is defined in > terms of libm_alias_float_r, etc., unless there's some reason that can't > work). ... I'm expanding from the explanation I provided in the declare_mgen_finite_alias thread. I suggest to read that message first. We can apply the same template techniques to provide *ibm128 functions that: 1. do not conflict with *l symbols that are reserved for the new long double ABI. 2. do not require a new API. We can redirect them from math.h using asm, in the same way used for finite or nldbl symbols.
On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > There is also gamma_r. Let me try to explain... There's no gamma_r public API at all. __gamma_r_finite is a bad ABI (__tgamma_finite would have been better, there's absolutely no need to handle the sign separately for tgamma) that unfortunately we're stuck with, but it's not type-generic because no wrapper is involved. > We can apply the same template techniques to provide *ibm128 functions that: But if you want to provide __*ibm128 (which seems to me to add ABIs unnecessarily), the right way is (a) to make ldbl-128ibm use libm_alias_ldouble (or similar) and (b) redefine that in the relevant case to define the additional aliases. (In any case, no new *ibm128_finite symbols should be added, because exported implementation-namespace libm functions are always once-per-format so you shouldn't need to add any more other than for obsolescent functions provided for long double but not float128.)
Joseph Myers <joseph@codesourcery.com> writes: > On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > >> There is also gamma_r. Let me try to explain... > > There's no gamma_r public API at all. __gamma_r_finite is a bad ABI > (__tgamma_finite would have been better, there's absolutely no need to > handle the sign separately for tgamma) that unfortunately we're stuck > with, but it's not type-generic because no wrapper is involved. Ack. > the right way is (a) to make ldbl-128ibm use > libm_alias_ldouble (or similar) and (b) redefine that in the relevant case > to define the additional aliases. We're doing this. > (In any case, no new *ibm128_finite > symbols should be added, because exported implementation-namespace libm > functions are always once-per-format so you shouldn't need to add any more > other than for obsolescent functions provided for long double but not > float128.) In this case, how would users continue to use IBM long double finite functions?
On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > > (In any case, no new *ibm128_finite > > symbols should be added, because exported implementation-namespace libm > > functions are always once-per-format so you shouldn't need to add any more > > other than for obsolescent functions provided for long double but not > > float128.) > > In this case, how would users continue to use IBM long double finite functions? They'd compile with -ffinite-math-only -mabi=ibmlongdouble, which would result in *l calls being redirected to __*l_finite. Whereas compiling with -ffinite-math-only -mabi=ieeelongdouble would result in *l calls being redirected to __*f128_finite (which already exist, so no new symbols are needed there at all except I suppose __scalbf128_finite). You need to change how math.h defines some macros for including bits/math-finite.h to achieve the above, but you don't need to add any new *_finite exports (other than __scalbf128_finite) because those are implementation-namespace exports, so one per format not one per type (and even if you add new *l symbol versions for public functions, which I don't think is necessary but you may have a case for based on what you've tried for later patches in the series, that definitely shouldn't be done for these implementation-namespace functions). Likewise no new variants of functions such as __issignaling* are needed; just make __MATH_TG do the right thing (I *think* the internal uses of __MATH_TG within libm in math-underflow.h, which currently expect suffixes used by __MATH_TG to be those for the types for the current compilation, should in fact still work without needing changing).
diff --git a/math/w_lgamma_r_template.c b/math/w_lgamma_r_template.c index ca54e42b61..880ff8065e 100644 --- a/math/w_lgamma_r_template.c +++ b/math/w_lgamma_r_template.c @@ -26,14 +26,6 @@ # include <math.h> # include <math_private.h> -#define M_DECL_FUNC_R_X(x) x ## _r -#define M_DECL_FUNC_R_S(x) M_DECL_FUNC_R_X (x) -#define M_DECL_FUNC_R(x) M_DECL_FUNC_R_S (M_SUF (x)) - -#define M_CALL_FUNC_R_X(x) x ## _r -#define M_CALL_FUNC_R_S(x) M_CALL_FUNC_R_X (x) -#define M_CALL_FUNC_R(x) M_CALL_FUNC_R_S (M_SUF (x)) - FLOAT M_DECL_FUNC_R (__lgamma) (FLOAT x, int *signgamp) { diff --git a/sysdeps/generic/math-type-macros.h b/sysdeps/generic/math-type-macros.h index c86ac3361e..2e3f227b4f 100644 --- a/sysdeps/generic/math-type-macros.h +++ b/sysdeps/generic/math-type-macros.h @@ -124,4 +124,16 @@ # define M_DECL_FUNC(f) M_SUF (f) #endif +#ifndef M_DECL_FUNC_R +# define M_DECL_FUNC_R_X(x) x ## _r +# define M_DECL_FUNC_R_S(x) M_DECL_FUNC_R_X (x) +# define M_DECL_FUNC_R(x) M_DECL_FUNC_R_S (M_SUF (x)) +#endif + +#ifndef M_CALL_FUNC_R +# define M_CALL_FUNC_R_X(x) x ## _r +# define M_CALL_FUNC_R_S(x) M_CALL_FUNC_R_X (x) +# define M_CALL_FUNC_R(x) M_CALL_FUNC_R_S (M_SUF (x)) +#endif + #endif /* _MATH_TYPE_MACROS */
Thread-safe math functions (*_r) have a different naming scheme that doesn't fit the M_SUF() / M_DECL_FUNC() mechanism. Move the M_DECL_FUNC_R() implementation from w_lgamma_r_template.c to math-type-macros.h in order to reuse these macros in other functions. 2018-05-11 Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> * math/w_lgamma_r_template.c (M_DECL_FUNC_R_X, M_DECL_FUNC_R_S, M_DECL_FUNC_R): Moved to... * sysdeps/generic/math-type-macros.h (M_DECL_FUNC_R_X, M_DECL_FUNC_R_S, M_DECL_FUNC_R): ... here. Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> --- math/w_lgamma_r_template.c | 8 -------- sysdeps/generic/math-type-macros.h | 12 ++++++++++++ 2 files changed, 12 insertions(+), 8 deletions(-)