[LLVMdev] Emitting IR in older formats (for NVVM)

[Samuel F Antao]

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>