[PATCH] Bitcode: Add bitcode format compatibility test

[Vedant Kumar]

David brings up a good point (re: overlap with existing bitcode tests). However, I think having a unified, comprehensive test is worthwhile. It`d be nice to have a single, easy-to-extend .ll file for IR compatibility work.


> On Jul 22, 2015, at 3:36 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> I don't think everyone has been as vigilant.

I can confirm this :). There haven`t been any bitcode tests checked in for function prefix/prologue data. While testing I found a uselistorder serialization problem here. The patch for this is on my to-do list, but briefly, we can trigger the issue with:

; RUN: verify-uselistorder < %s
@a = global i32 0
@b = global i32 0
declare void @c() prefix i32 0

Our bitcode compatibility support for comdats, function personalities, and metadata are also a little spotty IMO.


> I thought the plan of record for doing this compatibility testing was to have one compatibility.ll file which exercises all IR features, and then at every release point we assemble that IR file to compatibility-N.M.ll and add a RUN line for it. If your IR is exhaustive, could it serve as the basis for this going forwards?

That`s the plan I was following. I`ve tried to make the IR exhaustive. It`s split up into sections which mirror the logical progression of the LangRef. There are labels for each section/sub-section to make it easy to extend.


> On Wed, Jul 22, 2015 at 3:10 PM, David Blaikie <dblaikie at gmail.com> wrote:
> Not sure about everyone else, but I tried to add regression tests whenever I've changed the bitcode format, so I'm not sure how much it's necessary to have a generic test like this. I could imagine coverage isn't great & this might help - if it's easy to quantify, that might be interesting to know.

Unfortunately this isn`t easy to quantify. If we decide that having a comprehensive IR test is the way to go, I`d volunteer to remove/subsume redundant tests.


> On Wed, Jul 22, 2015 at 2:02 PM, Vedant Kumar <vsk at apple.com> wrote:
> Successive versions of LLVM should retain the ability to parse bitcode
> generated by old releases of the compiler. To that end, I've attached a
> patch which contains a bitcode format compatibility test. It's set up as a
> regression test. It achieves good coverage of the 3.7 LangRef (excepting a
> bunch of intrinsics).
> 
> The test consists of two files:
> 
>     o test/Bitcode/compatibility-3.7.ll
>     o test/Bitcode/compatibility-3.7.ll.bc
> 
> We should always be able to disassemble the bitcode file and exactly recover
> the original IR.
> 
> I've tried to stress as much of the LangRef as possible. I'm still trying
> to find a good way of testing format compatibility for intrinsics.
> 
> I'd have preferred to split this patch up into smaller ones, but since it
> contains a binary file I thought it'd be best to get it done in one shot. I
> don't have commit rights, so I'd appreciate someone taking a look at the
> patch and getting it into trunk :).
> 
> thanks!
> vedant
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
>