[LLVMdev] Clarification on the backward compatibility promises

[Bob Wilson]

> On Jul 9, 2014, at 3:09 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> 
>> 
>> On Jun 17, 2014, at 1:24 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> 
>> On 17 June 2014 16:07, Anton Korobeynikov <anton at korobeynikov.info> wrote:
>>> Hi Rafael,
>>> 
>>>> Do others agree that this is the case or at least that this would be a
>>>> reasonable balance?
>>> IMO it's easier to be compatible on .ll level, no?
>> 
>> That is not my experience with the bitcode format. The way the API is
>> structured makes it really easy to support backwards compatibility.
>> 
>> It also seems a lot more valuable from an user perspective to support
>> reading old .bc files. It means they can keep a library with IR for an
>> entire major LLVM release for example.
>> 
>>> In case of binary
>>> IR it's really easy to make incompatible changes. After all there are
>>> no tests on IR binary compatibility, however the whole regression
>>> testsuite can be viewed as a big test for .ll compatibility.
>> 
>> We do have tests that are done by checking in old versions of bitcode
>> files. We didn't use to be good about it, but I think we are now
>> fairly systematic about it any time we change the format.
>> 
>>> There are two more points here:
>>> 
>>> 1. Actually we had much stronger policies wrt the bitcode
>>> compatibility in minor releases. Something like x.y should be able to
>>> read stuff from x.y-1, but x.y+2 is allowed not to read stuff there,
>>> so the proper path is transition x.y-1 => x.y => x.y+2. Am I right?
>> 
>> That doesn't match what we have in trunk right now.  For example, we
>> changed how inline asm is stored in r163185 (Sep 5 2012), but we still
>> support reading the old one. This is one of the cases where we have a
>> FIXME about 4.0.
> 
> My understanding is newer version of LLVM should be able read older version with the same major release. And the .0 of the new major release must be able to read the bitcode of the previous major release. I think this is the right policy. We haven’t done a good job enforcing the policy, but we should.

That was also my understanding of our policy.

You are right that we need to do a better job of testing this. We have some ad-hoc tests for particular bitcode auto-upgrades but nothing systematic. These tests just read binary bitcode files, run them through llvm-dis, and check for the expected output. An initial step to improve the situation would be to write similar tests that attempt to exercise every IR feature, not just the things that we already know need to be upgraded from old bitcode. We would need to adopt the convention of extending these tests whenever something is added to the IR. Whenever we make a release, we would make a copy this set of tests corresponding to that release and we would continue to run those tests on trunk, e.g., reading the bitcode from the 3.5 release. The expected output for these tests might need to be updated occasionally. I would want to try to pack these systematic tests into as few files as possible, ideally only one, so that it is easier to make copies as part of the release process. I don’t know if that is feasible, especially for checking target-specific intrinsics, but it would be a nice goal.

Any feedback on that proposal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/e4c3cc57/attachment.html>