[LLVMdev] Clarification on the backward compatibility promises
Sean Silva
chisophugis at gmail.com
Wed Jun 18 09:13:25 PDT 2014
On Tue, Jun 17, 2014 at 2:07 PM, 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? 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.
>
This is a really good point. Theoretically (and to a good approximation in
practice), every feature of the IR is tested in the test suite in .ll form,
which means that a compatibility break at the .ll level will cause visible
churn. The same cannot be said for the bitcode.
-- Sean Silva
>
> 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?
> 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?
>
> > 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
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/2291546b/attachment.html>
More information about the llvm-dev
mailing list