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

[Nuno Lopes]

Hi,

So I cleaned up that code since LLVM doesn't produce those bytecodes  
since 3.0.
Since 2 versions have passed, I thought no one would really care.

Do you really need to remain binary compatible with LLVM 3.0?
I can revert the patch if there's a consensus that we shouldn't break  
compatibility.

Nuno


Citando Bill Wendling <wendling at apple.com>:

> Ah! I see what you mean. That makes sense.
>
> -bw
>
> On May 22, 2012, at 2:29 PM, Stephen Hines wrote:
>
>> I think you misunderstood my point. This is the kind of change that  
>> Chris agreed we should not be making for LLVM except on major (i.e.  
>> 3.0, 4.0, ...) releases. I realize that this just may be something  
>> that got missed for removal with 3.0, but it seems like bad form to  
>> be doing this.
>>
>> Steve
>>
>> On Tue, May 22, 2012 at 2:23 PM, Bill Wendling <wendling at apple.com> wrote:
>> 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