[LLVMdev] Clarification on the backward compatibility promises

[Sean Silva]

On Wed, Jun 18, 2014 at 10:35 AM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 18 June 2014 17:10, Sean Silva <chisophugis at gmail.com> wrote:
> >> >> 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.
>
> Well, I can only speak for myself, but in my two recent IR changes
> (cmpxchg failure orderings and cmpxchg weak"), I preserved bitcode
> compatiblity but not .ll. In both cases I was adding extra information
> to the instruction, which meant the bitcode reading section just had
> to insert a sensible default if that field wasn't present.
>
> In the first case, I could have kept IR compatibility, but the second
> (r210903) would have been rather difficult. It would involve examining
> all uses of the cmpxchg to find out whether the type expected was
> compatible with the new or the old version.
>

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.

At face value, this seems like a pretty compelling argument that the
bitcode is easier to version and keep compatible.

-- Sean Silva


> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/23d89eb0/attachment.html>