[LLVMdev] Clarification on the backward compatibility promises

[Tim Northover]

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.

Cheers.

Tim.