llvm dev - Nov 2021 - NVPTX codegen for llvm.sin (and friends)

>
> 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>

[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>

On Wed, Nov 17, 2021 at 12:17 PM Jon Chesterfield <
jonathanchesterfield at gmail.com> wrote:
> 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.
>
I should've phrased it better. What I mean is that because the __nv_*
functions are provided as IR, Replacing intrinsics with calls to __nv_
functions may provide further IR optimization opportunities -- inlining,
CSE, DCE, etc.. I didn't mean the optimizations based on known semantics of
the functions. I agree that those should be done for canonical calls only.

--Artem


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