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

Artem Belevich via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 17 12:56:26 PST 2021


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>


More information about the llvm-dev mailing list