<div dir="ltr">Hi Justin,<div><br></div><div>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 <a href="http://clang-omp.github.io/">http://clang-omp.github.io/</a> 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.</div><div><br></div><div>Many thanks,</div><div>Samuel</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-13 21:30 GMT-05:00 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 4:01 PM, Jonathan Ragan-Kelley <span dir="ltr"><<a href="mailto:jrk@csail.mit.edu" target="_blank">jrk@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<span></span><span><div>Thanks, all.</div>
<div><br></div>
<div>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.</div><span>
<blockquote class="gmail_quote"><div dir="ltr"><div>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.</div></div></blockquote>
</span><div>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.</div></span>
</div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div></div>
</font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>