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><div><br /></div><div>-MH<br /><br /><p>On January 12, 2015, Tobias Grosser <tgrosser@inf.ethz.ch> wrote:</p><blockquote type="cite"><div class="oneComWebmail-mail"><div class="oneComWebmail-body">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 target="_blank" href="https://github.com/KhronosGroup/SPIR-Tools/tree/master/spir-encoder/llvm_3.5_spir_encoder">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 />LLVMdev@cs.uiuc.edu         <a target="_blank" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br /><a target="_blank" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br /></div></div></blockquote></div>