[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/

[Devang Patel]

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 }
?:)
-
Devang


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