[LLVMdev] New Attribute Group broke bitcode compatibility

[Tobias Grosser]

On 07/09/2013 05:59 PM, Tobias Grosser wrote:
> On 05/24/2013 05:26 AM, Diego Novillo wrote:
>> Author: dnovillo
>> Date: Fri May 24 07:26:52 2013
>> New Revision: 182638
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=182638&view=rev
>> Log:
>> Add a new function attribute 'cold' to functions.
>>
>> Other than recognizing the attribute, the patch does little else.
>> It changes the branch probability analyzer so that edges into
>> blocks postdominated by a cold function are given low weight.
>>
>> Added analysis and code generation tests.  Added documentation for the
>> new attribute.
>
> It seems this commit broke bitcode compatibility with LLVM 3.3, but
> surprisingly not with LLVM 3.2. This suggests that 3.2 did not yet
> depend on the order of the attribute enum whereas 3.3 somehow seems
> to depend on it. This may be related to Bill's attribute refactoring.

Hi Bill,

I just looked a little more into the above problem and it seems the 
bitcode writer support for the new attribute code produces unstable 
bitcode. The problem is in BitcodeWriter.cpp, where the new 
WriteAttributeGroupTable() writes out the attributes using this piece of 
code:

         if (Attr.isEnumAttribute()) {
           Record.push_back(0);
           Record.push_back(Attr.getKindAsEnum());
         } else if (Attr.isAlignAttribute()) {
           Record.push_back(1);
           Record.push_back(Attr.getKindAsEnum());
           Record.push_back(Attr.getValueAsInt());

getKindAsEnum() returns the actual value of the enum, which is then 
stored in the bitcode. This direct connection makes the bitcode 
dependent of the order of elements in the enum, which causes changes
like the above to break bitcode compatibility. Specifically, bitcode 
from LLVM 3.3 is currently incompatible to bitcode from LLVM trunk.

Do you have any plans to fix this or should I give it a shot?

Cheers,
Tobias