Hello, 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. 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. Cheers, Joe ______________________________ Joe Abbey Director of Software Development Arxan Technologies jabbey at arxan.com<mailto:jabbey at arxan.com> www.arxan.com<http://www.arxan.com/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/273a334e/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/273a334e/attachment.txt> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/273a334e/attachment.htm>
Hi Joe,> 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? Ciao, Duncan.> > 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. > > Cheers, > > Joe > *______________________________* > *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 > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Joe, > >> 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? > > Ciao, Duncan. >I could for my immediate headache. My concern is that there will be future updates to the bitcode representation that may not work in this flow. That's impossible to predict, and llvm-dis -> .ll -> llvm-as is one path which certainly seems attractive. By providing an internal switch to emit bitcode, I think we save a step and have a method for future proofing. I'll be talking about this in a lightning talk, perhaps others have thoughts on this. Joe