[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

Sean Silva chisophugis at gmail.com
Fri Oct 31 18:21:59 PDT 2014


Hi all,

Doug Yung started a discussion earlier (
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077227.html)
about using the unused "version" field in the bitcode wrapper, and I think
there was some misunderstanding. I'd like to clarify the motivation.

The reason we want to add the version field is to easily identify "old"
bitcode. It is only LLVM version granularity, but that is good enough for
us. The obvious thing is that we offer compatibility, so why do we need to
know the bitcode version? There are really two reasons:

1. In the short term, LLVM does theoretically provide compatibility.
However, we at Sony are under a much stronger commitment to our customers
than the open source project here, so until the test infrastructure is
beefed up quite a bit to improve this confidence in the backwards
compatibility promise, the version field is a quick unobtrusive way for us
to behave correctly in the short term. Beefing up the compatibility testing
is a separate discussion that everybody realizes is a much larger long-term
endeavor; we at Sony are glad to help with that. As we prepare for our
first official SDK release with LTO, where our customers are officially
sanctioned to feed bitcode to our tools, a solution is needed though. I
think that existing toolchains with LTO will also benefit from this in the
near-term.

2. In the long term, it *will* break across major releases. Currently I
don't think we have a way to identify this. This is a bit longer-term
perspective, but it will eventually come up and this fixes it.


Also, is there a reason why the bitcode wrapper is Darwin-specific? Can we
just always use it and simplify the code path?

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/bd0e6d2e/attachment.html>


More information about the llvm-dev mailing list