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

[Duncan Sands]

Hi Dale,

> > 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.
> 
> Not sure I'm understanding this.  The layout of structs is not  
> something we can
> change around:   we need to be runtime-compatible with gcc.  (There have
> been bugs in this area and perhaps still are, but that's the eventual  
> requirement.)

this doesn't change anything as far as llvm-gcc is concerned.  Consider
struct {
  long double d;
  char c;
}
The gcc size for long double is 12 bytes on my machine (the gcc size is always
equal to getABITypeSize), so when we convert this struct in llvm-types we get
the following specification from gcc:
  long double d at offset 0
  charc c at offset 12
Before, we would add padding when converting this to LLVM, to make up for the
difference in types sizes, giving the following LLVM struct:
  long double <- 10 bytes (offset 0)
  char [2] <- 2 bytes of padding (offset 10)
  char <- 1 byte (offset 12)
Now that long double has the same size in LLVM as in gcc, we convert this to:
  long double <- 12 bytes (offset 0)
  char <- 1 byte (offset 12)

So the only effect of this change should be that we no longer need to pad
structs containing x86 long doubles.

> IIRC this was previously achieved by looking at the alignment.  Are you
> just achieving the same layout a different way (I have no objection), or
> is the layout changing?

The same layout is being achieved a different way.

Best wishes,

Duncan.