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

[Michael Haidl]

Since SPIR can be (easily) transformed to NVVM IR at least for me this helps a lot.

Thank you Tobias.
-MH


On January 12, 2015, Tobias Grosser <tgrosser at inf.ethz.ch> wrote:
> On 12.01.2015 05:48, Jonathan Ragan-Kelley wrote:
> > 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:
> > 
> > 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.
> > 
> > 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.
> > 
> > So that's the challenge.
> > 
> > The obvious questions are:
> > 
> > 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?
> > 
> > 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.
> > 
> Dear Jonathan,
> 
> the following link may help:
> 
> <https://github.com/KhronosGroup/SPIR-Tools/tree/master/spir-encoder/llvm_3.5_spir_encoder>
> 
> From the documentation:
> 
> spir-encoder
> ------------
> This utility provides a mechanism to produce LLVM bitcode compatible
> with the SPIR 1.2 specification when working with recent versions of
> LLVM. Specifically, this tool takes a SPIR module generated using LLVM
> 3.5 and outputs bitcode using LLVM 3.2 encoding. This tool assumes
> that the SPIR module is valid, and does not perform any
> transformations to the module.
> 
> Even though spir is just a subset of LLVM-IR, it may actually be generic enough for your purposes.
> 
> Cheers,
> Tobias
> 
> _______________________________________________
> 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/20150113/7aefa358/attachment.html>