<div dir="ltr"><div>Does anyone have anything else to say about .bc/.ll compatibility? It is important to be clear to users about what compatibility we provide. I'd like to get consensus about this and put it in the docs somewhere.<br>
<br>-- Sean Silva<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 11:15 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 18, 2014 at 10:35 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On 18 June 2014 17:10, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<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>
>> 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>
><br>
> Could you elaborate more on this?<br>
><br>
> My anecdotal experience is that the .ll is more stable. I remember last<br>
> summer that in multiple situations passing the old .bc (from the 3.1-based<br>
> or 3.2-based SCE compiler IIRC) to trunk would cause it to barf, while<br>
> passing the .ll file would not barf. I don't think I would be able to<br>
> reproduce this without a lot of work, so I'm just leaving this as an<br>
> anecdote.<br>
<br>
</div>Well, I can only speak for myself, but in my two recent IR changes<br>
(cmpxchg failure orderings and cmpxchg weak"), I preserved bitcode<br>
compatiblity but not .ll. In both cases I was adding extra information<br>
to the instruction, which meant the bitcode reading section just had<br>
to insert a sensible default if that field wasn't present.<br>
<br>
In the first case, I could have kept IR compatibility, but the second<br>
(r210903) would have been rather difficult. It would involve examining<br>
all uses of the cmpxchg to find out whether the type expected was<br>
compatible with the new or the old version.<br></blockquote><div><br></div></div></div><div>I briefly looked at r210903, and it seems like the reason that it was easier to maintain the bitcode compatibility is that the size of the record implicitly identifies whether the record was written before or after the change. I.e., it would have been as though you had introduced a "cmpxchgpossiblyweak" instruction that has the new return type, so that you can tell which it is without extensive analysis.<br>

<br></div><div>At face value, this seems like a pretty compelling argument that the bitcode is easier to version and keep compatible.<br></div><div><br></div><div>-- Sean Silva<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<br>
Cheers.<br>
<span><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>