search for: libnvvm

I can't seem to find a direct answer. If I want to convert NVVM IR to PTX code, do I have to use libNVVM or can I use a publicly released version of LLVM? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130131/2067682b/attachment.html>

...nd up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK? -- lg On Dec 9, 2013, at 7:00 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). > > To generate...

This question is specifically motivated by the practical constraints of NVVM, but I don't know anywhere better to ask (hopefully, e.g., @jholewinski is still following), and I believe it concerns general LLVM issues: NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL text parsers are from that generation. It's interface calls for adding modules as either bitcode blobs or LL text buffers. LLVM's bitcode and assembly formats have never been intended to maintain strong cross-version compatibility. However...

...ote: > > This question is specifically motivated by the practical constraints of > > NVVM, but I don't know anywhere better to ask (hopefully, e.g., > > @jholewinski is still following), and I believe it concerns general LLVM > > issues: > > > > NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL > > text parsers are from that generation. It's interface calls for adding > > modules as either bitcode blobs or LL text buffers. LLVM's bitcode and > > assembly formats have never been intended to maintain strong > &...

Thanks, all. I didn’t realize a 7.0 RC was public and changed to 3.4—I will go down that road for now, though I’ll probably also look into integrating variants of the SPIR converter in the future. Another possibility is to skip libnvvm altogether and use LLVM's NVPTX target.  This is of course harder since you have to configure the passes yourself instead of just calling a few C functions, but it does give you more control over the optimization pipeline and gives you full visibility into the compiler.  Unfortunately, there ar...

Hi, I wonder whether the current version of LLVM supports separate compilation and linking of device code, i.e., is there a flag analogous to nvcc's --relocatable-device-code flag? If not, is there any plan to support this? Thanks! Yuanfeng Peng -------------- next part -------------- An HTML attachment was scrubbed... URL:

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: