(original) (raw)

On Fri, Mar 12, 2021 at 1:51 PM Artem Belevich via llvm-dev <llvm-dev@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?