[LLVMdev] New Attribute Group broke bitcode compatibility
Tobias Grosser
tobias at grosser.es
Tue Jul 16 10:14:07 PDT 2013
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
More information about the llvm-dev
mailing list