[llvm-commits] [126245] Fix http://lists.cs.uiuc.edu/pipermail/llvm-commits/ Week-of-Mon-20070416/047943.html

Devang Patel dpatel at apple.com
Tue Apr 17 13:57:32 PDT 2007


Hi,

if
	(StartOffsetInBits > FirstUnallocatedByte*8)

is true then
	
	(StartOffsetFromByteBoundry == 0)

is always true. If so, we could simply this even further. In other  
words, if we need pad bytes for a new field then it always starts at  
byte boundary. Can you think of an example where this is not true ?

Thanks,
-
Devang

On Apr 17, 2007, at 1:42 PM, Duncan Sands wrote:

> Hi Devang, I just posted a fix which fixes some other issues too.
> A few lines earlier:
>
>    if (StartOffsetFromByteBoundry != 0) {
>      // New field does not start at byte boundry.
>      PadBits = StartOffsetInBits - (FirstUnallocatedByte*8);
>      PadBytes = PadBits/8 + 1;
>    }
>
>    PadBytes += StartOffsetInBits/8-FirstUnallocatedByte;
>
> If StartOffsetFromByteBoundry != 0, then PadBytes gets added to twice,
> setting it to 2*PadBits/8 + 1.
>
>>       Pad = ArrayType::get(Pad, PadBytes);
>>     Info.addElement(Pad, FirstUnallocatedByte, PadBytes);
>>     FirstUnallocatedByte = StartOffsetInBits/8;
>> -    // This field will use some of the bits from this PadBytes.
>> -    FieldSizeInBits = FieldSizeInBits - (PadBytes*8 - PadBits);
>> +    // This field will use some of the bits from this PadBytes, if
>> +    // starting offset is not at byte boundry.
>> +    if (StartOffsetFromByteBoundry != 0)
>> +      FieldSizeInBits = FieldSizeInBits - (8 - PadBits);
>
> Here PadBits can be bigger than 8, which will lead to a bad result :)
> Even if it is less than 8 this can create a negative FieldSizeInBits.
> For example, if FieldSizeInBits=1, StartOffsetFromByteBoundry=1, then
> typically PadBits=1, meaning you are setting FieldSizeInBits to -6  
> here!
>
>>   }
>>
>>   // Now, Field starts at FirstUnallocatedByte and everything is  
>> aligned.
>
> Best wishes,
>
> Duncan.




More information about the llvm-commits mailing list