[LLVMdev] [PATCH] -emit-bitcode-version
baldrick at free.fr
Thu Nov 8 00:31:10 PST 2012
> We have a tool which reads in bitcode, processes it, and re-emits it. We use
> this tool as a flexible way to integrate our tool into the Xcode, Android NDK,
> Chromium, and Linux build process.
> The problem we face is that bitcode changes, and when it does… future versions
> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn
> can BitcodeReader from LLVM 3.1, but LLVM 3.1 can't BitcodeReader LLVM 3.2
> (after r165739.) There was an element of this patch which would have helped
> enable bitcode compatibility (use-abs-operands), but alas it was not committed.
can't you use a combination of llvm-dis (from LLVM 3.2) and llvm-as (from LLVM
3.1) to convert the bitcode?
> This patch is essentially those missing lines, but with a new purpose of
> providing a vehicle for bitcode compatibility. With this patch, I aim to enable
> clang-3.2 or beyond to produce a bitcode that llc 3.1 code read. Or when
> LLVM-3.5 creates a new encoding… LLVM-3.3 might have a chance of still reading
> it by disabling that feature.
> There's only two options right now:
> 0 ) which basically means absolute ids
> 1) which basically means relative ids.
> I'm more than happy to document and maintain this actively, as we've been far
> too long passively monitoring and shifting with the changes.
> So there's a bunch missing, and I'm trying to figure out how to create a clang
> option which would configure the CurrentVersion.
> Traditional testing will be a challenge, since it requires the use of an older
> llvm to verify, but I'm also willing to brainstorm on this. Perhaps I can create
> a custom build-slave on my buildbots to verify this on an on-going basis.
> *Joe Abbey*
> Director of Software Development
> Arxan Technologies
> jabbey at arxan.com <mailto:jabbey at arxan.com> www.arxan.com <http://www.arxan.com/>
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev