[LLVMdev] Clarification on the backward compatibility promises

[Sean Silva]

On Tue, Jun 17, 2014 at 2: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.
>

Could you elaborate more on this?

My anecdotal experience is that the .ll is more stable. I remember last
summer that in multiple situations passing the old .bc (from the 3.1-based
or 3.2-based SCE compiler IIRC) to trunk would cause it to barf, while
passing the .ll file would not barf. I don't think I would be able to
reproduce this without a lot of work, so I'm just leaving this as an
anecdote.

-- Sean Silva



>
> 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.
>
> > 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.
>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/cd5907f9/attachment.html>