[LLVMdev] Clarification on the backward compatibility promises

[Evan Cheng]

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

> 
>> 2. Metadata compatibility. We already had precedence of introducing
>> incompatible changes into metadata format in the past within release.
>> Should we use relaxes rules for metadata compatibility?
> 
> I think we have a special case for debug metadata (and should document
> that), but otherwise I think we should hold metadata to the same
> standard as the rest of the IR.

I agree.

Evan
> 
>>> In any case, we should probably document whatever we decide. Where
>>> should that go? Sean suggested docs/DeveloperPolicy.html. Is everyone
>>> OK with that?
>> +1
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev