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

[Rafael Espíndola]

> Right, that version number is used to resolve *ambiguities* in how to
> interpret some chunk of bitcode.  It is not a generic bitcode version
> scheme, because most bitcode format changes involve things like adding
> new operands or opcodes, which are easily identified without needing
> an explicit version number.

That is what it is used for at the moment. It is is just a number, we
can increment it as often as we want.

> The scenario I am most concerned about is this:
>
> - We as a vendor publish toolchain #12 based on SVN r250000.
> - During subsequent LLVM development, changes happen (!).
>   For example, a new key letter 'g' in the Data Layout.  This is
>   not a bitcode ambiguity so MODULE_CODE_VERSION is unchanged.
> - We as a vendor publish toolchain #13 based on SVN r300000.
> - Some middleware provider publishes libIncrediblyUseful.bc built
>   using spiffy new toolchain #13.
> - Some hapless game developer tries to use libIncrediblyUseful.bc
>   but is still on toolchain #12. This causes an error during some
>   LTO build phase, of course; the question is, what kind of error
>   and how does Hapless Game Developer know what to do?

In summary. An old tool reading new bitcode. It should report that the
particular new feature is not support. In this case, something like
"unknown 'g' flag in datalayout".

> This does *nothing* for Hapless Game Developer.  HGD wants to see
> "this bitcode file was generated by a newer version, I don't understand
> how to interpret it" because _that's_ the actual problem.

We can probably add a note saying "newer or corrupt BC".

> Proposed solution:
>
> Whether to emit a bitcode wrapper becomes a target-dependent predicate.

Again, *any* solution involving the bitcode wrapper is not interesting
to the open source project since it is not required.

Cheers,
Rafael