[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility

[Moritz Angermann via llvm-dev]

> Patches welcome :)
How about
> - deprecation of accepted bitcode versions will be announce two versions ahead?

> 
>> 
>> I’m essentially generating bitcode without using the llvm bitcode writer,
> 
> You may be interested in this not-totally-related-but-still thread: http://lists.llvm.org/pipermail/llvm-dev/2016-September/105273.html
> What’s your motivation? Is it to support a front-end written in another language?

The Glasgow Haskell Compiler has had a llvm backend for some time now, however it generated textual
ir and therefore each version was tied to a specific llvm version (llvm 3.7, as of GHC 8.0).

My primary interest is to make ghc more mobile friendly (read iOS, and Android). Shaving that yak
lead me to down a rabbit hole, which made me question the choice of textual ir. After being pointed
to the developer policy on the #llvm irc channel and it was suggested to use bitcode ir, I started
out to write a pure haskell bitcode writer[1]. GHC uses an intermediate language (C--) as the input
to the llvm and native code generator. I’m currently translating this into the llvm module that the
bitcode writer can serialize.

> From the old documentation, you were also assured that 4.0 will be the last release to read 3.x bitcode.

Precisely, it gave me a rough hint when the potentially last version that’s going to support 3.x was going
to happen, by extrapolating the releases.

> Because we have no plan to drop support for it at that time, we just wrote that we support bitcode for every release since 3.0.
> Does it mean that this will never change? No, we can’t make any guarantee of course. But if it were to change we wouldn’t do it overnight either, and surely we would plan this a few releases ahead.

I’m not trying to fix bitcode into eternity :-) And yes, if this info was provided in addition to what
is already  provided, this would be perfect, I think!

>> Also, will there be a 5.X series? Or will there be 5.0 be followed by 6.0?
> 
> 6.0 will follow ~6 months after 5.0 according to the current plan.

Thanks! Can I find these planned release infos somewhere?

Cheers,
 Moritz

—
[1]: It consists of four levels:
     - data-bitcode (simple bitcode reader / writer)      https://github.com/angerman/data-bitcode
     - data-bitcode-llvm (llvm bitcode reader / writer)   https://github.com/angerman/data-bitcode-llvm
     - data-bitcode-edsl (edsl for the data-bitcode-llvm) https://github.com/angerman/data-bitcode-edsl
     - data-bitcode-plugin (a ghc plugin that replaces the ghc compilation pipeline) https://github.com/angerman/data-bitcode-plugin