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

[Roman Lebedev via llvm-dev]

I would like to note that there's prior (and generic!) art in this
area - ReplaceWithVeclib (https://reviews.llvm.org/D95373)
Presumably the NVPTX backend only needs to declare
the wanted replacements, and they //should// already happen.


Roman

On Wed, Nov 17, 2021 at 11:49 PM Liu, Yaxun (Sam) via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> [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!
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev