# NVPTX codegen for llvm.sin (and friends)

**URL:** <https://discourse.llvm.org/t/nvptx-codegen-for-llvm-sin-and-friends/58170>\
**Category:** LLVM Dev List Archives\
**Created:** [April 29, 2021, 11:25pm UTC](https://discourse.llvm.org/t/nvptx-codegen-for-llvm-sin-and-friends/58170 "2021-04-29T23:25:20Z")\
**Posts on this page:** 1\
**Showing post:** 33

<div class="post-metadata">

**Author:** ![jdoerfert](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/jdoerfert/32/18220_2.png) [@jdoerfert](https://discourse.llvm.org/u/jdoerfert)\
**Post date:** [May 8, 2024, 10:30am UTC](https://discourse.llvm.org/t/nvptx-codegen-for-llvm-sin-and-friends/58170/33 "2024-05-08T10:30:13Z")

</div>

> [@jhuber6](#):
>
> Are we talking about making the backend expand things like `llvm.sin` fully?

No, but if the backend does, that should not be disturbed (as it is the “best” solution).  
We basically want to have the following flow:

- llvm.math flows in (or is created at some point) which is understood by the optimizer
- libm comes in that implements llvm.math (via attributes)
- backends report what intrinsics they support natively
- a pass in the middle end replaces llvm.math with libm calls
- inliner and IPO have a chance to optimize the call sites

---

_[View the full topic](https://discourse.llvm.org/t/nvptx-codegen-for-llvm-sin-and-friends/58170)._