[llvm-dev] NVPTX codegen for llvm.sin (and friends)

[Jon Chesterfield via llvm-dev]

>
> SGTM.
> Providing a fixed set of replacements for specific intrinsics is all
> NVPTX needs now.
> Expanding intrinsics late may miss some optimization opportunities,
> so we may consider doing it earlier and/or more than once, in case we
> happen to materialize new intrinsics in the later passes.
>

Good old phase ordering. I don't think we've got any optimisations that
target the nv/oc named functions and would personally prefer to never
implement any.

We do have ones that target llvm.libm, and some that target extern C
functions with the same names as libm. There's some code in clang that
converts some libm functions into llvm intrinsics, and I think some other
code in clang that converts in the other direction. Maybe dependent on
various math flags.

So it seems we either canonicalise libm-like code and rearrange
optimisations to work on the canonical form, or we write optimisations that
know there are N names for essentially the same function. I'd prefer to go
with the canonical form approach, e.g. we could rewrite calls to __nv_sin
into calls to sin early on in the pipeline (or ignore them? seems likely
applications call libm functions directly), and rewrite calls to sin to
__nv_sin late on, with optimisations written against sin.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211117/7680f18d/attachment.html>