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

[Sean Silva]

On Mon, Nov 24, 2014 at 7:53 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > 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".
>

This makes sense to me. I think it is pretty safe to assume that any
"invalid bitcode" that an end-user would get their hands on is just because
the bitcode is from a newer version.

-- Sean Silva


>
> > 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141124/4014b416/attachment.html>