llvm dev - Jun 2014 - [LLVMdev] Clarification on the backward compatibility promises

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.

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>

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>