[PATCH] D12618: Reserve a vendor reserved block ID for bitcode

[Mehdi Amini via llvm-commits]

> On Sep 9, 2015, at 4:59 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 9 September 2015 at 18:36, Chandler Carruth <chandlerc at google.com> wrote:
>> Two points.
>> 
>> One, we have the idea of backwards compat until a major version bump. If
>> we're going to do this, we should write a record with the epoch of
>> compatibility as a monotonically increasing integer IMO. It seems crazy to
>> not have a way to check that the bitcode file is at least *plausible* to
>> auto-upgrade. That seems reasonable for the open source project in general.
>> 
>> Second, unless there is a pressing need to handle this in an opaque
>> vendor-specific way, I'd love to find an approach that could even be useful
>> to open source developers. Let me propose an alternative, and maybe you can
>> tell me where it falls over: we could add both a hard compatibility epoch
>> counter, and a version string. The version string would literally contain a
>> munged string just like 'clang --version' does. We can stash SVN revisions,
>> release numbers, and whatever else your heart desires in there. Then, when
>> the bitcode reader fails for some reason, as part of a more helpful error
>> message, we use these strings in the two bitcode files to try to form a
>> helpful error message:
>> 
>> "ld: Error parsing bitcode file in libFooBar.a (generated by LLVM rNNNN,
>> read by LLVM rMMMM)" or some such.
>> 
>> Thoughts?
> 
> I like the idea of an unstructured version string that is printed once
> an error is found by some other way.
> 
> Note that we don't have to add the epoch right now, since its absence
> can be read as epoch 0.
> 
> One issue with the epoch idea is that we would then be dropping big
> version ranges at a time. Once we get to 4.1 we can choose to drop
> compatibility with 3.X. If we want to drop with all of 3.X the epoch
> works fine, but what if only revisions < 3.5 are problematic enough
> that we want to drop it? Should the epoch be updated more often than
> that?


Our internal prototype of the vendor block contains a “magic” at the beginning of the block, followed by the version number, followed by a string to be user friendly.
It is not very different from what the epoch would provide, but I’m not sure I understand the proposal about when to increment it?

Also our release does not match the open-source LLVM release, it is not clear how the epoch is supposed to interact on this aspect?


Thanks,

— 
Mehdi