[LLVMdev] Clarification on the backward compatibility promises

Bob Wilson
2014-09-16T18:49:51Z

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