[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

[Chris Lattner]

On Oct 31, 2014, at 11:44 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> Jumping late at these threads, but my opinion with my open source hat on is:
> 
> * We want to support backwards compatibility in the bitcode file. In
> the past, we have not done a good job at it, but if someone wants to
> do the extra testing, any issues found would be considered real bugs
> and if reported are very likely to be fixed.

I agree with Rafael on this.  The hard part here is to do the testing: once problems are identified, it is straight-forward to do the auto-upgrading logic.  If you don’t plan to do the auto-upgrade, then we’ve failed in our mission and using a version number doesn’t seem like much to feel good about.

> * The backwards compatibility for debug info is far less strict, but
> we already have a version info for that. We currently drop it on
> mismatch, but it would be trivial to have an option to error instead.

Right.  There is also work underway to improve debug information in a number of ways, these changes should also help improve its stability.

> * When we get to 4.1 we might want to drop compatibility with some
> older bitcodes from the 3.X era. If we then also want to be able to
> reuse enum values (linkage for example), adding a marker/version when
> we get to 4.0 might make sense, but it would include only the major
> version.

Honestly, I think we should evaluate it when we get there.  In the 2.x to 3.0 era, there was a huge benefit from dropping the 2.x compatibility junk, given that bitcode was new in the 2.x timeframe.  I think it is good that we’re reserving the right to drop compatibility when 4.0 rolls around, but unless there is a major win, we should consider keeping 3.x support in the compiler.

-Chris