[PATCH] Bitcode: Add bitcode format compatibility test

[Duncan P. N. Exon Smith]

> 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?