[libc][math][AMDGPU] Implement GPU math functions

[jhuber6]

Tracking Issue: Missing GPU Math Functions in LLVM libm

This is a tracking issue for math functions present in existing GPU math libraries that are not currently provided by the LLVM libm.

C Standard Functions

• acos
• acosh
• asin
• asinh
• atan [libc][math] Implement fast pass for double precision atan function. #132333
• atan2
• atanh
• erf
• erfc
• lgamma
• scalb
• sinh
• tanh
• tgamma
• sinpi
• pown

Complex Functions

• cabs
• cacos
• cacosh
• casin
• casinh
• catan
• catanh
• ccos
• ccosh
• cexp
• clog
• cosh
• csin
• csinh
• csqrt
• ctan
• ctanh

POSIX Functions

• j0
• j1
• y0
• y1

OpenCL / GPU Extensions

• powi
• minmag
• maxmag

[llvmbot]

@llvm/issue-subscribers-libc

Author: Joseph Huber (jhuber6)

This is a tracking issue for math functions present in the existing GPU math libraries not currently provided by the LLVM libm.

C standard functions

acos
acosh
asin
asinh
atan
atan2
atanh
erf
erfc
lgamma
scalb
signbit
sinh
tanh
tgamma

Complex functions

cabs
cacos
cacosh
casin
casinh
catan
catanh
ccos
ccosh
cexp
clog
cosh
csin
csinh
csqrt
ctan
ctanh

POSIX functions

j0
j1
y0
y1

OpenCL / GPU extensions

powi
pown
minmag
maxmag
sinpi

[AnonMiraj]

Hello,

I’m new to LLVM, and I was wondering if it’s fine for me to try implementing asin. The approach I’m thinking of is similar to how atan was done using range reduction and a Taylor polynomial to achieve good accuracy.

I also curious about something, would it be enough to compute acos directly from asin? If not, why?

[jhuber6]

Hello,

I’m new to LLVM, and I was wondering if it’s fine for me to try implementing asin. The approach I’m thinking of is similar to how atan was done using range reduction and a Taylor polynomial to achieve good accuracy.

I also curious about something, would it be enough to compute acos directly from asin? If not, why?

I was actually just talking with @lntue about those functions. The main difficulty in the LLVM-libc is that we try to make all functions correctly rounded by default. That seems to be the difficult part when it comes to these arc functions. The GPU relaxes this, allowing some ULP at least within what OpenCL specifies.

I'd love for some more people to work on the missing functions, so hopefully @lntue can help you along. He's currently looking at those two I believe.

[lntue]

Hello,

I’m new to LLVM, and I was wondering if it’s fine for me to try implementing asin. The approach I’m thinking of is similar to how atan was done using range reduction and a Taylor polynomial to achieve good accuracy.

I also curious about something, would it be enough to compute acos directly from asin? If not, why?

To answer your question, yes, acos and asin will share the core computations, as you can see with acosf and asinf:
https://github.com/llvm/llvm-project/blob/main/libc/src/math/generic/acosf.cpp#L94
https://github.com/llvm/llvm-project/blob/main/libc/src/math/generic/asinf.cpp#L125

As @jhuber6 mentioned, the difficulty for double precision asin and acos will come from correct rounding requirement and testing. And I'm actually finishing these 2 functions. If you are new to floating point computations and interested in implementing them, I would suggest you to try 2 very similar functions asinpi and acospi for float16 (asinpif16, acospif16) and float (asinpif, acospif). Feel free to create issues for that and tag us to assign it to you.

[lntue]

@AnonMiraj in case you are curious about asin and acos: #134401