Jonathan Ragan-Kelley
2015-Jan-13 21:01 UTC
[LLVMdev] Emitting IR in older formats (for NVVM)
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 are some NVVM-specific optimizations missing upstream that we are not able to contribute back. I appreciate the suggestion, but this is actually for a project which has been using NVPTX for years. The problem is that we see (dramatically) better performance from our OpenCL backend (via CL C source kernels) on NVIDIA hardware simply because kernels actually get optimized through the full NVCC-style stack. Based on related experience in other projects, I expect NVVM to provide a similar or greater bump over NVPTX. In short, I’d *love* to stick with NVPTX and the open source stack in LLVM trunk, but until it provides competitive performance on real programs (which, in my experience so far, it ~never does), it’s unfortunately not a strong alternative. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/a0cc49f7/attachment.html>
Do you have some examples you can share? I would be interested in taking a look to see what we can do to help improve the performance of NVPTX, especially relative to equivalent OpenCL code. On Tue, Jan 13, 2015 at 4:01 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote:> 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 are some NVVM-specific >> optimizations missing upstream that we are not able to contribute back. >> > I appreciate the suggestion, but this is actually for a project which has > been using NVPTX for years. The problem is that we see (dramatically) > better performance from our OpenCL backend (via CL C source kernels) on > NVIDIA hardware simply because kernels actually get optimized through the > full NVCC-style stack. Based on related experience in other projects, I > expect NVVM to provide a similar or greater bump over NVPTX. In short, I’d > *love* to stick with NVPTX and the open source stack in LLVM trunk, but > until it provides competitive performance on real programs (which, in my > experience so far, it ~never does), it’s unfortunately not a strong > alternative. >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/bd0b7452/attachment.html>
Hi Justin, We are working on a project that tries to bring OpenMP support for systems that comprise PPC and Nvidia GPUs, using the LLVM backends. We are currently working on the OpenMP version of clang maintained in github http://clang-omp.github.io/ which currently uses 3.5 IR level but in the process to start contributing our changes to trunk. We came across the exact same issue described here. I see you mentioned you not being able to contribute some NVVM specific changes back. Could you elaborate on that? Is that due to the confidential nature of the code or lack of time to implement and maintain these changes? If it is the latter we have in our team people interested in helping with that. Many thanks, Samuel 2015-01-13 21:30 GMT-05:00 Justin Holewinski <justin.holewinski at gmail.com>:> Do you have some examples you can share? I would be interested in taking > a look to see what we can do to help improve the performance of NVPTX, > especially relative to equivalent OpenCL code. > > On Tue, Jan 13, 2015 at 4:01 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> > wrote: > >> 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 are some NVVM-specific >>> optimizations missing upstream that we are not able to contribute back. >>> >> I appreciate the suggestion, but this is actually for a project which has >> been using NVPTX for years. The problem is that we see (dramatically) >> better performance from our OpenCL backend (via CL C source kernels) on >> NVIDIA hardware simply because kernels actually get optimized through the >> full NVCC-style stack. Based on related experience in other projects, I >> expect NVVM to provide a similar or greater bump over NVPTX. In short, I’d >> *love* to stick with NVPTX and the open source stack in LLVM trunk, but >> until it provides competitive performance on real programs (which, in my >> experience so far, it ~never does), it’s unfortunately not a strong >> alternative. >> > > > > -- > > Thanks, > > Justin Holewinski > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/e9a1af13/attachment.html>