Hi Jonathan, <div><br /></div><div>I am using NVVM in my PhD These I presented at the LLVM-HPC workshop at SC14 called PACXX. I encountered the same problem about a year ago. I'm using clang 3.5 to generate IR from C++14 code an had to get rid of the attributes as you pointed out. I have a little opt pass that runs after code generation and as one of its task it removes all attributes. However, it seems that libNVVM does not care about attributes at all. Only a few attributes are supported (see 3.11 from the NVVM IR specifications) basically controlling inlining, But I can't look inside libNVVM so it's a wild guess and clarification would be nice how far function attributes influence PTX generation. </div><div><br /></div><div>Regarding your questions: </div><div>1. If there is a way to create IR that is backward compatible with 3.2, then I realy want to hear about it. However, I doubt there is one. When I started using NVVM I read somewhere that backward compatibility is never a property targeted for LLVM IR. </div><div><br /></div><div>Cheers, </div><div>Michael Haidl</div><br /><p>On January 12, 2015, Jonathan Ragan-Kelley <jrk@csail.mit.edu> wrote:</p><blockquote type="cite"><div class="oneComWebmail-html oneComWebmail-mail"><div class="oneComWebmail-body"><div dir="ltr"><span style="font-size: 13px;">This question is specifically motivated by the practical constraints of NVVM, but I don't know anywhere better to ask (hopefully, e.g., @jholewinski is still following), and I believe it concerns general LLVM issues:</span><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL text parsers are from that generation. It's interface calls for adding modules as either bitcode blobs or LL text buffers. LLVM's bitcode and assembly formats have never been intended to maintain strong cross-version compatibility. However, this means that a compiler built on more recent LLVMs struggles mightily to emit even simple IR for NVVM to compile.</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">Specifically, I find 3.4 (the official Ubuntu package) generates both bitcode streams and LL text which are incompatible with the 3.2 parser in the current NVVM release (6.5). I'm hardly surprised that the binary format changes, but simple examples generally manage fine in LL text. Nontrivial modules, however, do not. Specifically, the first issue I notice is that `#i` attribute references (as opposed to inline attributes) appear to be a recent addition to the assembly syntax; they are always used by the assembly serializer (when, e.g., streaming out a Module) for any function attributes in generated assembly, but cannot be parsed by the NVVM/3.2 parser. This seems to be the main compatibility issue, but it's hard to tell without first eliminating it and then proceeding further.</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">So that's the challenge.</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">The obvious questions are:</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">1. Narrowly, is it possible to coerce the standard LLVM bitcode or text writers to emit more conservative/backwards-compatible output (specifically with an eye towards NVVM/3.2)? Am I just going to have to resort to brittle string rewrites on the generated text to inline all #attr values?</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">2. More generally, is there another accepted way to create NVVM programs from LLVM-based compilers which use versions more recent than 3.2? I can't imagine I'm the first one to run into this—3.2 is fairly old at this point, and NVVM seems wedded to its interface for stability reasons.</div><div style="font-size: 13px;"><br /></div><div style="font-size: 13px;">Many thanks.</div><div style="font-size: 13px;">-jrk</div></div>
</div></div><div class="oneComWebmail-mail"><div class="oneComWebmail-body">_______________________________________________<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>