[llvm-commits] [llvm] r43620 - in /llvm/trunk: include/llvm/Target/ lib/Analysis/ lib/CodeGen/SelectionDAG/ lib/ExecutionEngine/ lib/ExecutionEngine/Interpreter/ lib/ExecutionEngine/JIT/ lib/Target/ lib/Transforms/IPO/ lib/Transforms/Scalar/ lib/Transforms/Utils/

[Chris Lattner]

On Nov 1, 2007, at 6:43 PM, Devang Patel wrote:

>
> On Nov 1, 2007, at 1:53 PM, Duncan Sands wrote:
>
>> Finally, I made one change which I think wise but others might
>> consider pointless and suboptimal: in an unpacked struct the
>> amount of space allocated for a field is now given by the ABI
>> size rather than getTypeStoreSize.  I did this because every
>> other place that reserves memory for a type (eg: alloca) now
>> uses getABITypeSize, and I didn't want to make an exception
>> for unpacked structs, i.e. I did it to make things more uniform.
>> This only effects structs containing long doubles and arbitrary
>> precision integers.  If someone wants to pack these types more
>> tightly they can always use a packed struct.
>
> Naively, I just used getTypeSizeInBits() clang yesterday. I'll sync  
> up clang once dust settles on llvm side in next day or two.
>
> Now, how far we are from ability to use arbitrary precision integers  
> to represent struct bit fields directly ?
>
> translating
> 	struct STest4 {char a; int b:2; int c:3; int d; } st4;
> into
>         %struct.STest4 = type { i8, i2, i3, i32 }
> instead of
>         %struct.STest4 = type { i8, i8, i32 }
> ?:)
>
We won't ever want to do that.  "apints in structs" will be stored  
with their extra bits as garbage: they won't pack together. {i2, i3}  
will take two bytes for example.  In practice, we will always have to  
compile the above into  { i8, i8, i32 }.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20071101/58bc2e79/attachment.html>