<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 3:36 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think everyone has been as vigilant. Most people aren't checking in old bitcode when they switch the writer to produce a new record.<div><br></div><div>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?</div></div></blockquote><div><br></div><div>I don't recall us ever settling on anything. There was a thread `[LLVMdev] [RFC] Exhaustive bitcode compatibility tests for IR features` where Steven Wu proposed something similar, but that discussion tailed off. Key domain experts in bitcode compatibility like the RenderScript folks didn't participate strongly.</div><div><br></div><div>Overall I think that the approach Steven was suggesting (and which it seems like Vedant is following) is an improvement over the current state of affairs, though is hardly "exhaustive" (which is part of the confusion in the prevoius discussion; realistically a different approach is needed for being "exhaustive"; but "exhaustive" is not actually a goal for anyone I don't think).</div><div><br></div><div>It would be interesting to collect some empirical data about how much effort this release-to-release work is, and which, if any, existing compatibility problems are caught. Vedant, could you maybe retroactively do the expected release-to-release work for the last couple LLVM revisions and see what you find, and how much effort it is?</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 3:10 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jul 22, 2015 at 2:02 PM, Vedant Kumar <span dir="ltr"><<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Successive versions of LLVM should retain the ability to parse bitcode<br>
generated by old releases of the compiler. To that end, I've attached a<br>
patch which contains a bitcode format compatibility test. It's set up as a<br>
regression test. It achieves good coverage of the 3.7 LangRef (excepting a<br>
bunch of intrinsics).<br>
<br>
The test consists of two files:<br>
<br>
o test/Bitcode/compatibility-3.7.ll<br>
o test/Bitcode/compatibility-3.7.ll.bc<br>
<br>
We should always be able to disassemble the bitcode file and exactly recover<br>
the original IR.<br>
<br>
I've tried to stress as much of the LangRef as possible. I'm still trying<br>
to find a good way of testing format compatibility for intrinsics.<br>
<br>
I'd have preferred to split this patch up into smaller ones, but since it<br>
contains a binary file I thought it'd be best to get it done in one shot. I<br>
don't have commit rights, so I'd appreciate someone taking a look at the<br>
patch and getting it into trunk :).<br>
<br>
thanks!<br>
<span><font color="#888888">vedant<br>
<br>
</font></span><br></div></div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>