[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