https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502
--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Joseph S. Myers from comment #0) > GCC should support inline code generation for asinh, acosh, atanh functions, > under appropriate fast-math conditions. > > glibc's bits/mathinline.h, for 32-bit non-SSE fast-math x86 only, has: > > /* The argument range of the inline version of asinhl is slightly reduced. > */ > __inline_mathcodeNP (asinh, __x, \ > register long double __y = __fabsl (__x); \ > return (log1pl (__y * __y / (__libc_sqrtl (__y * __y + 1.0) + 1.0) + __y) > \ > * __sgn1l (__x))) > > __inline_mathcodeNP (acosh, __x, \ > return logl (__x + __libc_sqrtl (__x - 1.0) * __libc_sqrtl (__x + 1.0))) > > __inline_mathcodeNP (atanh, __x, \ > register long double __y = __fabsl (__x); \ > return -0.5 * log1pl (-(__y + __y) / (1.0 + __y)) * __sgn1l (__x)) > > We're moving away from such inlines in glibc, preferring to leave it to the > compiler to inline standard functions under appropriate conditions. This > inlining probably only makes sense when logl / log1pl are themselves > expanded inline (but in principle it's otherwise generic; note this x86 code > uses long double, so avoiding reducing the argument range for built-in > functions for narrower types). (__sgn1l is another inline function, copying > the sign of x to the value 1.0L.) Can you please advise, which would be appropirate conditions? I think that they should be similar to hypot conditions - flag_finite_math_only and flag_unsafe_math_optimizations. The x87 expansion is valid for float and double functions, we should leave out long double variant, even with flag_unsafe_math_optimizations.
