<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 1:51 PM Artem Belevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, bitcode is<span class="gmail_default" style="font-family:verdana,sans-serif"> </span>platform specific. I can imagine building a bitcode file during the<br>
build but shipping one means you have to know ABI and datalayout or<br>
hope they are the same everywhere.<br></blockquote><div><br></div><div><div style="font-family:verdana,sans-serif">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.</div></div><div><br></div><div><div style="font-family:verdana,sans-serif">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.</div><br></div><div><div style="font-family:verdana,sans-serif">OK. I'll agree that that may be a bit too much for now.</div></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div></div></div>