[PATCH] Bitcode: Add bitcode format compatibility test

[Sean Silva]

On Thu, Jul 30, 2015 at 5:50 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2015-Jul-30, at 15:45, Vedant Kumar <vsk at apple.com> wrote:
> >
> > I've updated the patch with Sean's feedback in mind (and Duncan's input).
> >
> > This version of the patch includes a 3.6-compatible IR and a
> corresponding bitcode blob generated by llvm-3.6.2. The bitcode blob
> generated by llvm-trunk is gone now.
> >
> > I'm happy to report that llvm-trunk can parse the 3.6.2 bitcode without
> issue. When 3.7 is officially released, we can add a 3.7 bitcode blob and
> start working on compatibility-3.8.ll.
> >
> > Could someone look over this patch and commit it if it looks good?
> >
> > vedant
> >
> > <bccompat-submit.patch>
> >
>
> > diff --git a/test/Bitcode/compatibility-3.6.ll
> b/test/Bitcode/compatibility-3.6.ll
> > new file mode 100644
> > index 0000000..12a8e41
> > --- /dev/null
> > +++ b/test/Bitcode/compatibility-3.6.ll
>
> Would it be better to call this *-3.6.2.ll?  I'm not actually sure.
>
> I don't think we'll want more than one bitcode file per release... so
> maybe it's okay as is?  Certainly, the comment inside should be
> specific.
>
> > diff --git a/test/Bitcode/compatibility-3.7.ll
> b/test/Bitcode/compatibility-3.7.ll
> > new file mode 100644
> > index 0000000..46aebba
> > --- /dev/null
> > +++ b/test/Bitcode/compatibility-3.7.ll
>
> I think it would be better to call this file:
>
>     test/Bitcode/compatibility.ll
>
> We should be updating this file every time we add some new type of IR,
> so keeping it free of a version number will make that more clear (and
> make its history easier to read).
>
> That gives us (initially) these files:
>
>     test/Bitcode/compatibility.ll
>     test/Bitcode/compatibility-3.6.ll
>     test/Bitcode/compatibility-3.6.ll.bc
>
> For 3.7, I guess we'll have to cherry-pick this commit over to the
> branch.  By the time 3.7 has been tagged, the trunk version is liable
> (likely?) to have moved ahead.  Maybe, even, it already has?
>
> Once 3.7 is tagged, we should copy the branch's copy of compatibility.ll
> over to compatibility-3.7.ll on trunk, and generate the corresponding
> compatibility-3.7.ll.bc.  Then (on trunk) we'll have:
>
>     test/Bitcode/compatibility.ll
>     test/Bitcode/compatibility-3.6.ll
>     test/Bitcode/compatibility-3.6.ll.bc
>     test/Bitcode/compatibility-3.7.ll
>     test/Bitcode/compatibility-3.7.ll.bc
>
> This process (and the compatibility.ll file itself) should be documented
> somewhere, or else people won't know to update it when they add things
> to the IR.
>
> Sean, any ideas?  Maybe in docs/LangRef.rst itself?


LangRef might work, but it would probably be lost among all the stuff
there; the argument could also be made that LangRef is basically about the
IR itself, but this content is more about development process/tasks.

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility is
another possibility, which I'm leaning towards, since this is all in
connection with compatibility.

Another possibility is to add it as an explicit task in
http://llvm.org/docs/HowToReleaseLLVM.html, but that may implicitly put the
burden of doing this on the release manager, which may not be intended
(maybe could be added as "track down somebody to do this once we've
branched"?).

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150730/86955b0b/attachment.html>