<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 2:24 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 17 June 2014 16:07, Anton Korobeynikov <<a href="mailto:anton@korobeynikov.info">anton@korobeynikov.info</a>> wrote:<br>

> Hi Rafael,<br>
><br>
>> Do others agree that this is the case or at least that this would be a<br>
>> reasonable balance?<br>
> IMO it's easier to be compatible on .ll level, no?<br>
<br>
</div>That is not my experience with the bitcode format. The way the API is<br>
structured makes it really easy to support backwards compatibility.<br></blockquote><div><br></div><div>Could you elaborate more on this?<br><br>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.<br>
<br></div><div>-- Sean Silva<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also seems a lot more valuable from an user perspective to support<br>
reading old .bc files. It means they can keep a library with IR for an<br>
entire major LLVM release for example.<br>
<div class=""><br>
>In case of binary<br>
> IR it's really easy to make incompatible changes. After all there are<br>
> no tests on IR binary compatibility, however the whole regression<br>
> testsuite can be viewed as a big test for .ll compatibility.<br>
<br>
</div>We do have tests that are done by checking in old versions of bitcode<br>
files. We didn't use to be good about it, but I think we are now<br>
fairly systematic about it any time we change the format.<br>
<div class=""><br>
> There are two more points here:<br>
><br>
> 1. Actually we had much stronger policies wrt the bitcode<br>
> compatibility in minor releases. Something like x.y should be able to<br>
> read stuff from x.y-1, but x.y+2 is allowed not to read stuff there,<br>
> so the proper path is transition x.y-1 => x.y => x.y+2. Am I right?<br>
<br>
</div>That doesn't match what we have in trunk right now.  For example, we<br>
changed how inline asm is stored in r163185 (Sep 5 2012), but we still<br>
support reading the old one. This is one of the cases where we have a<br>
FIXME about 4.0.<br>
<div class=""><br>
> 2. Metadata compatibility. We already had precedence of introducing<br>
> incompatible changes into metadata format in the past within release.<br>
> Should we use relaxes rules for metadata compatibility?<br>
<br>
</div>I think we have a special case for debug metadata (and should document<br>
that), but otherwise I think we should hold metadata to the same<br>
standard as the rest of the IR.<br>
<div class=""><br>
>> In any case, we should probably document whatever we decide. Where<br>
>> should that go? Sean suggested docs/DeveloperPolicy.html. Is everyone<br>
>> OK with that?<br>
> +1<br>
<br>
</div>Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>