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

[Kuperstein, Michael M]

Hi,

We need to remain binary compatible to our own old versions, which is rather problematic if it doesn't happen in upstream. 
Assuming the community agrees, it would help us if this patch was reverted.

Michael

-----Original Message-----
From: Nuno Lopes [mailto:nunoplopes at sapo.pt] 
Sent: Wednesday, May 23, 2012 01:34
To: Bill Wendling; Kuperstein, Michael M
Cc: Stephen Hines; llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [llvm] r156383 - in /llvm/trunk: include/llvm/Bitcode/LLVMBitCodes.h lib/Bitcode/Reader/BitcodeReader.cpp

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
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.