[libc-commits] [PATCH] D152486: [libc] Begin implementing a 'libmgpu.a' for math on the GPU

[Johannes Doerfert via Phabricator via libc-commits]

jdoerfert added a comment.

In D152486#4410351 <https://reviews.llvm.org/D152486#4410351>, @sivachandra wrote:

> It might be appealing to provide a normal math.h like interface via the libc project, but at that point, why should it be the libc project which should provide it?

Whoever provides math.h should provide the implementation. As you mentioned, two places will cause problems.

> You can do all of this outside of the libc project. We ideally want the bring up of libc project's math on a new target architecture to be like this:
>
> 1. Implement platform specific primitives. Example, `fma` operations, `fenv` manipulation functions.
> 2. As the primitives are being implemented, start adding math functions to the list of entrypoints.
>
> Any reason why we cannot take this approach? May be there are certain operational reasons. For example, if some functions come from the libc project and the rest from elsewhere, who provides the `math.h` header file?
>
> Another point to keep in mind is that the libc project's math implementations come with an additional promise: the results they produce are correctly rounded in all rounding modes. Which means they produce the same result on any target architecture which is IEEE-754 compliant, in all rounding modes.

@jhuber6 wants to get rid of the vendor math, but for now that is all we have. It would be great to have compliant alternatives, if they are as fast, or a choice for the user. Right now we have neither.

All that said, what would be a better place for the math impl for GPUs, which for now is vendor based? It seems to me that next to libc_gpu is the right place, but if you insist we cannot do this we need an alternative.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152486/new/

https://reviews.llvm.org/D152486