[cfe-dev] [LLVMdev] Proposal to add Bitcode version field to bitcode file wrapper

[Eric Christopher]

On Mon, Sep 29, 2014 at 8:58 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>
>> On Sep 29, 2014, at 7:29 AM, Renato Golin <renato.golin at linaro.org> wrote:
>>
>> On 29 September 2014 15:16, Robinson, Paul
>> <Paul_Robinson at playstation.sony.com> wrote:
>>> That promise is what I understood from a discussion within the past month,
>>> e.g. http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076815.html
>>> If I misunderstood, clarification on the clarification would be helpful. ;-)
>>
>> I see, I missed that one. My concerns seem to be similar to Bob's,
>> though in the past, when we discussed the same topic, there was one
>> major hurdle to implement that: we'd have to know what features we
>> removed / stopped supporting and warn on what version brackets
>> supported that feature. This can only grow as the compiler ages.
>>
>> Enforcing backwards compatibility with only the major version created
>> another hurdle: we'd only be able to deprecate bad/temporary features
>> every few years, creating another bag of legacy. Warnings can be made,
>> and deprecation of whole sets of features will happen at major
>> version, which will stress the release validation and increase the
>> influx of bugs on all major releases.
>>
>> Whenever I think of any of that, I remember Chris' words: "LLVM IR is
>> a compiler IR. Nothing more, nothing less". I don't think we should
>> try to standardise that too much.
>
> It is a compiler IR but with LTO we need backward compatibility for IR in object files. This is not a new requirement. We have required auto-upgrade support for old bitcode files for as long as I have worked on LLVM for exactly this reason. The testing to enforce that has been pretty minimal, but we’re now making an effort to be more systematic about it.

Except, backward compatibility breaks are allowed at major versions.
See, for example, the type system rewrite.

-eric