[libc-commits] [PATCH] D153395: Populating 'libmgpu.a' for math on the GPU
Matt Arsenault via Phabricator via libc-commits
libc-commits at lists.llvm.org
Mon Jul 31 11:19:23 PDT 2023
arsenm added inline comments.
================
Comment at: libc/src/math/gpu/vendor/amdgpu/declarations.h:45
double __ocml_sin_f64(double);
+float __ocml_sincos_f32(float, float *);
+double __ocml_sincos_f64(double, double *);
----------------
jhuber6 wrote:
> arsenm wrote:
> > jhuber6 wrote:
> > > arsenm wrote:
> > > > This won't actually work, the underlying pointer uses a private pointer. you can't simply declare as flat and call it. Probably should just define the struct return variant and use that. it's a lot less ugly than dealing with the pointer wrapping
> > > Variables declared on the stack should be private as far as I know. I figured the semantics are the same as the regular `sincos` where we just write to whatever pointer we're given. If it's a stack pointer it'll be private, if it's a global it won't be and it'll be up to the user to not have that conlift.
> > The ocml functions aren’t magic. This is declared with the wrong type
> Ah, so internally it expects private pointers and we need to make sure that whatever address space cast is required is done prior to calling it? I'm assuming that'll be something like `__attribute__((address_space(5)))` and we'll need to manually convert from it. I may need to have some utility header that assigns global, private, and local address spaces depending on the target since this is all pure C++ without the standard address space checks you'd get in OpenCL or something.
Yes. I'm looking into adding the stret variants but having a naming things is hard problem
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D153395/new/
https://reviews.llvm.org/D153395
More information about the libc-commits
mailing list