[llvm-commits] [llvm] r156383 - in /llvm/trunk: include/llvm/Bitcode/LLVMBitCodes.h lib/Bitcode/Reader/BitcodeReader.cpp

[Bill Wendling]

Actually, if that's the case, now is the perfect time to remove the old opcode. The 3.1 release is finished now, and we're deep into 3.2 development already.

-bw

On May 22, 2012, at 2:07 PM, Stephen Hines wrote:

> I thought that the consensus from the most recent LLVM Developer Conference was to not remove opcode support except on major releases. Deprecating an opcode (not using it further with BitcodeWriter) and generating new opcodes was considered reasonable. This would seem to go directly against that. I would prefer that changes like this get reverted before 3.2.
> 
> Steve
> 
> On Tue, May 22, 2012 at 2:01 PM, Bill Wendling <wendling at apple.com> wrote:
> On May 22, 2012, at 3:55 AM, Kuperstein, Michael M wrote:
> 
> > Hello,
> >
> > The commit below (156383) broke binary compatibility with LLVM 3.0.
> > The LLVM 3.1 branch generates bitcode files with the new TYPE_CODE_FUNCTION, and can read both. However, 3.0 still generated TYPE_CODE_FUNCTION_OLD (it is named TYPE_CODE_FUNCTION in 3.0, the change to OLD was made somewhere between 3.0 and the final 3.1 branch) records. This means 3.1 is still able to read 3.0 bitcode, but 3.2 will not be able to.
> >
> > I'm attaching a small test-case. I will be happy to provide a proper patch that resurrects TYPE_CODE_FUNCTION_OLD, if that's helpful.
> >
> I'm not really in favor of reverting this behavior. The old code was in there by accident. It's unfortunate that some bitcodes were generated with the outdated codes, but it's not something we should wish to perpetuate. There is a workaround: use the 3.0 or 3.1 `llvm-dis' tool to create a text version of the bitcode file and then run the new `llvm-as' on it.
> 
> -bw
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>