[LLVMdev] Clarification on the backward compatibility promises

[Sean Silva]

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.

-- Sean Silva


On Wed, Jun 18, 2014 at 11:15 AM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
>
> 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/20140621/e4f7063a/attachment.html>