[LLVMdev] The definition of getTypeSize

[Duncan Sands]

Hi Dale,

> I do not have a strong opinion on the naming of the various size  
> functions, or on how to deal with APInt's of sizes that are not  
> multiples of a byte.
> 
> I do think loading and storing more bytes than necessary is generally  
> a bad idea, especially if you're getting uninitialized bits.

I agree, and I agree that it is good that writing an x86 long double
stores 80 bits, not more.  I don't much like the idea of i36 writing
64 bits rather than 40 bits, but as an initial implementation this
seems ok to me.

> (If you incorrectly cross a page boundary, you might fault, for one thing.

I don't see how this can be a problem unless you write more than the
getABITypeSize, which would already be wrong for other reasons.  Well,
I guess if you do an unaligned store of an x86 long double 10 bytes
before the end of a page you could get a fault if 12 bytes are written.
But since llvm-gcc says that sizeof(long double)=12 (or more) the program
was incorrect anyway.
Another issue is what TYPE_SIZE gcc thinks an i36 has.  It would be
dangerous if the LLVM getABITypeSize was different.

> Watch out for packed structs.)

I don't see that that's a problem if getTypeSize (size of a store)
and getABITypeSize are both 8 bytes for an i36.

> I also think the current general approach to x86 long double is  
> best:  use 80 bits for the underlying size, and where extra bytes are  
> required for padding, do that by looking at the alignment.  There is  
> no need to allocate more than 10 bytes for scalars of this type, and  
> we currently don't for stack objects.

Don't forget that alloca can take a NumElements argument.  It sounds
like you would like alloca to allocate getTypeSize bytes when NumElements
is not specified, and NumElements*getABITypeSize when NumElements is specified
(you could imagine allocating getTypeSize bytes when NumElements is 1, but since
NumElements may be a variable this would IMHO complicate things nastily).
That sounds a bit dangerous to me (not uniform -> easier for optimizers to make
mistakes), but otherwise I've no real objection.  Maybe Chris can comment on this?

> (The code you point to in visitAlloca does look like it might be a  
> problem, but I can't make it fail.   Known-size arrays appear here as  
> a single object [3 x x86_f80], and the size is computed
> correctly; unknown-size arrays have the size of the elements passed  
> from the FE, and this includes padding.  How does that size*count  
> computation get executed?)

Since llvm-gcc tends to generate either an alloca without NumElements, or
an alloca with NumElements but for an i8, I doubt you can hit this without
hand crafting a test-case in LLVM assembler.

Best wishes,

Duncan.