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

[Justin Holewinski]

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.

The SPIR converter looks promising.  Since it doesn't actually interpret
the IR, things like address space mappings should transfer fine.

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.

On Tue, Jan 13, 2015 at 2:51 AM, Michael Haidl <haidl at pacxx.org> wrote:

> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/cfd8389e/attachment.html>