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

[Liu, Yaxun (Sam) via llvm-dev]

[AMD Official Use Only]

+1 but we may want to put it under a clang option in the beginning in case it causes perf degradation.

Sam

From: Jon Chesterfield <jonathanchesterfield at gmail.com>
Sent: Wednesday, November 17, 2021 3:17 PM
To: Artem Belevich <tra at google.com>
Cc: Johannes Doerfert <johannesdoerfert at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Arsenault, Matthew <Matthew.Arsenault at amd.com>; Evgenii Stepanov <eugenis at google.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>
Subject: Re: [llvm-dev] NVPTX codegen for llvm.sin (and friends)

[CAUTION: External Email]
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/fd7bfb0c/attachment.html>