Another question to you is how the functions will work with implicit conversion. What I would do is to force input be the same with is_same of enable_if, if they are available.

In D133400#3774781, @lntue wrote:

In D133400#3774132, @orex wrote:

Good job, Tue!

I have an optional suggestion. You can use formula
asin(x)=1/2*acos(1-2*x^2)
and, of course,
acos(x)=pi/2-asin(x)
for cases where |x|>=0.5 Probably it can be much faster than sqrt.

Thanks @orex for the suggestion! Unfortunately the formula asin(x) = pi/4 - 1/2 * asin(1 - 2*x^2) only works
well when |1 - 2*x^2| <= 0.5, i.e. 0.5 <= |x| <= sqrt(3)/2.

For sqrt(3)/2 < |x| <= 1, we still need some sort of range reduction involving square root.

Nonetheless, I've tried adding another branch for 0.5 <= |x| <= sqrt(3)/2 using the formula
asin(x) = pi/4 - 1/2 * asin(1 - 2*x^2) and it actually makes both the throughput and the latency
slightly worse than 2 branches.

Good job, Tue!

Review fixes.

Review fixes.

The aux functions are split into two files according @lntue suggestion.

Review fixes.

Fixed entrypoint.

Fixed comments.

Fix wrong upload.

Constants description added.

Thank you, Paul! I'll land the revision after Tue review.

In D131095#3699654, @tschuett wrote:

Did you consider using builtins with overflow checking:
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
It is platform independent and leaves some optimisations opportunities to the compiler.

Paul (@zimmermann6) and Tue (@lntue),

Rebased to latest main.

Thank you Paul for sharing the results.
The results I got using the same compiler (llvm 11) as Paul (@zimmermann6):

CORE_MATH_PERF_MODE=rdtsc PERF_ARGS='' ./perf.sh coshf
GNU libc version: 2.31
GNU libc release: stable
18.534
13.019
17.590
CORE_MATH_PERF_MODE=rdtsc PERF_ARGS='--latency' ./perf.sh coshf
GNU libc version: 2.31
GNU libc release: stable
49.670
38.334
50.461

As you can see llvm 12 significantly improve throughput of this version of coshf over version 11. Partially this problem can be explained by this difference. Another source of the difference is Intel vs AMD. We observe such difference with (@lntue).
Paul, can you confirm, that the precision is OK? I think that we can push the changes even though the solution is not the fastest for all platforms/compilers? Tue?

Review fixes.

Review fixes.

Review fixes. More verbose comments.

Review fixes.

Rebasing on main with small fixes.

Rebasing on main with small fixes.

Merged to last main, some cosmetic changes.

Small fixes in test.

Small fixes.

OK. Thanks! let's wait.

Added explicit dependencies.

Improved performance by fputil::nearest_integer function.

The easiest way, from my point of view, will be to apply it on top of working coshf branch, which you made and test.

Can you try to put all the chain on top of the revision 60d6be5dd3f411cfe1b5392cbb... for now. I'll rebase the revisions to the last main tonight.

Yes. You should first apply D129005, after D129215 and after that one. The initial revision were cut to several ones to improve review process and new function deployment.

Fix some reviewer comments.

Fix build problem.

Added sinhf/coshf