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

On Fri, Mar 12, 2021 at 1:51 PM Artem Belevich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Also, bitcode is platform specific. I can imagine building a bitcode file
>> during the
>> build but shipping one means you have to know ABI and datalayout or
>> hope they are the same everywhere.
>>
>
> Agreed. We will likely need multiple variants. We will compile
> specifically for NVPTX or AMDGPU and we will know specific ABI and the data
> layout for them regardless of the host we're building on.
>
> It appears to me is the the difference vs what we have now is that
we'll
> need to have the libm sources somewhere, the process to build them for
> particular GPUs (that may need to be done out of the tree as it may need
> CUDA/HIP SDKs) and having to incorporate such libraries into llvm
> distribution.
>
> OK. I'll agree that that may be a bit too much for now.
>
It sounded before like you were saying the library should effectively
be function aliases for standard libm names, to call __nv_ names. Isn't it
utterly trivial to generate such a bitcode file as part of the toolchain
build, without requiring any external SDKs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210312/e01d8a1a/attachment.html>

On Fri, Mar 12, 2021 at 2:39 PM James Y Knight <jyknight at google.com>
wrote:
>
>
> On Fri, Mar 12, 2021 at 1:51 PM Artem Belevich via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Also, bitcode is platform specific. I can imagine building a bitcode
>>> file during the
>>> build but shipping one means you have to know ABI and datalayout or
>>> hope they are the same everywhere.
>>>
>>
>> Agreed. We will likely need multiple variants. We will compile
>> specifically for NVPTX or AMDGPU and we will know specific ABI and the
data
>> layout for them regardless of the host we're building on.
>>
>> It appears to me is the the difference vs what we have now is that
we'll
>> need to have the libm sources somewhere, the process to build them for
>> particular GPUs (that may need to be done out of the tree as it may
need
>> CUDA/HIP SDKs) and having to incorporate such libraries into llvm
>> distribution.
>>
>> OK. I'll agree that that may be a bit too much for now.
>>
>
> It sounded before like you were saying the library should effectively
> be function aliases for standard libm names, to call __nv_ names. Isn't
it
> utterly trivial to generate such a bitcode file as part of the toolchain
> build, without requiring any external SDKs?
>
That's true for most, but not all functions provided by libdevice. We'd
still need something that's a bit more involved.

--Artem





-- 
--Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210312/d3f9cb6d/attachment.html>