<div dir="ltr">Yes, this is an issue we are keenly aware of. LLVM IR is not a stable storage format, and NVVM is therefore tied to a particular revision of the IR. You may want to give the 7.0 RC a try; this updates libnvvm to LLVM 3.4. There may still be incompatibilities with 3.5 or 3.6svn, but it should be better.<div><br></div><div>The SPIR converter looks promising. Since it doesn't actually interpret the IR, things like address space mappings should transfer fine.</div><div><br></div><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><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 2:51 AM, Michael Haidl <span dir="ltr"><<a href="mailto:haidl@pacxx.org" target="_blank">haidl@pacxx.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since SPIR can be (easily) transformed to NVVM IR at least for me this helps a lot. <div><br></div><div>Thank you Tobias. </div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">-MH</font></span><div><div class="h5"><br><br><p>On January 12, 2015, Tobias Grosser <<a href="mailto:tgrosser@inf.ethz.ch" target="_blank">tgrosser@inf.ethz.ch</a>> wrote:</p><blockquote type="cite"><div><div>On 12.01.2015 05:48, Jonathan Ragan-Kelley wrote:<br><blockquote>This question is specifically motivated by the practical constraints of<br>NVVM, but I don't know anywhere better to ask (hopefully, e.g.,<br>@jholewinski is still following), and I believe it concerns general LLVM<br>issues:<br><br>NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL<br>text parsers are from that generation. It's interface calls for adding<br>modules as either bitcode blobs or LL text buffers. LLVM's bitcode and<br>assembly formats have never been intended to maintain strong<br>cross-version compatibility. However, this means that a compiler built<br>on more recent LLVMs struggles mightily to emit even simple IR for NVVM<br>to compile.<br><br>Specifically, I find 3.4 (the official Ubuntu package) generates both<br>bitcode streams and LL text which are incompatible with the 3.2 parser<br>in the current NVVM release (6.5). I'm hardly surprised that the binary<br>format changes, but simple examples generally manage fine in LL text.<br>Nontrivial modules, however, do not. Specifically, the first issue I<br>notice is that `#i` attribute references (as opposed to inline<br>attributes) appear to be a recent addition to the assembly syntax; they<br>are always used by the assembly serializer (when, e.g., streaming out a<br>Module) for any function attributes in generated assembly, but cannot be<br>parsed by the NVVM/3.2 parser. This seems to be the main compatibility<br>issue, but it's hard to tell without first eliminating it and then<br>proceeding further.<br><br>So that's the challenge.<br><br>The obvious questions are:<br><br>1. Narrowly, is it possible to coerce the standard LLVM bitcode or text<br>writers to emit more conservative/backwards-compatible output<br>(specifically with an eye towards NVVM/3.2)? Am I just going to have to<br>resort to brittle string rewrites on the generated text to inline all<br>#attr values?<br><br>2. More generally, is there another accepted way to create NVVM programs<br>from LLVM-based compilers which use versions more recent than 3.2? I<br>can't imagine I'm the first one to run into this—3.2 is fairly old at<br>this point, and NVVM seems wedded to its interface for stability reasons.<br></blockquote><br>Dear Jonathan,<br><br>the following link may help:<br><br><a href="https://github.com/KhronosGroup/SPIR-Tools/tree/master/spir-encoder/llvm_3.5_spir_encoder" target="_blank">https://github.com/KhronosGroup/SPIR-Tools/tree/master/spir-encoder/llvm_3.5_spir_encoder</a><br><br>From the documentation:<br><br>spir-encoder<br>------------<br>This utility provides a mechanism to produce LLVM bitcode compatible<br>with the SPIR 1.2 specification when working with recent versions of<br>LLVM. Specifically, this tool takes a SPIR module generated using LLVM<br>3.5 and outputs bitcode using LLVM 3.2 encoding. This tool assumes<br>that the SPIR module is valid, and does not perform any<br>transformations to the module.<br><br>Even though spir is just a subset of LLVM-IR, it may actually be generic enough for your purposes.<br><br>Cheers,<br>Tobias<br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></div></div></blockquote></div></div></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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div></div>
</div>