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

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.

My tuppence.

--renato

> 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.

On 29 September 2014 16:58, Bob Wilson <bob.wilson at apple.com>
wrote:
> 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.
By all means, I think we're on the same page as far as testing and the
burden of keeping the compatibility, I just didn't remember it being
such a big requirement.

Maybe I'm making a bigger issue than it needs to be... which is
actually quite likely. :)

cheers,
--renato

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