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

[Jonathan Ragan-Kelley]

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.

Many thanks.
-jrk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150111/9e7e731e/attachment.html>