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

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>

On 22 June 2014 01:18, Sean Silva <chisophugis at gmail.com>
wrote:
> 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
>
To make this all a bit easier, how about making clang/llvm output a
version number at the beginning of the .ll or .bc file?
It would then be clear which version of clang/llvm wrote the file out.
You could then add warnings if clang/llvm thought they were
incompatible with the older version or not.

Kind Regards

James

On Sun, Jun 22, 2014 at 2:15 AM, James Courtier-Dutton <
james.dutton at gmail.com> wrote:
> On 22 June 2014 01:18, Sean Silva <chisophugis at gmail.com> wrote:
> > 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
> >
>
> To make this all a bit easier, how about making clang/llvm output a
> version number at the beginning of the .ll or .bc file?
> It would then be clear which version of clang/llvm wrote the file out.
> You could then add warnings if clang/llvm thought they were
> incompatible with the older version or not.
>
I don't think that would significantly help.

For .bc, the sizes of records already implicitly hold that information in a
more fine-grained and semantic way (not tied to versions, but rather
intrinsically to the change to the IR).
For .ll, it is too easy to end up with a file that has an nonexistent or
inconsistent version number (such as a hand-written file) so we wouldn't be
able to rely on it.

Anyway, that's sort of a separate discussion. For now, I'd like to focus
strictly on deciding what guarantees we offer.

-- Sean Silva

>
> Kind Regards
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140622/b8ddc676/attachment.html>