[LLVMdev] fields in structure re-arranged for alignment?

[Chris Lattner]

On Mon, 16 Jul 2007, Kean Lau wrote:
> Bear with me, I'm a newbie to LLVM.

Welcome,

> I've read the language reference and the mailing list archive. One area of
> the semantics of the Structure type that hasn't been discussed is whether
> fields in the structure get re-arranged to better suit the target machine's
> natural alignment, ala what happens in C.

> For example would this structure on a 32-bit machine:
> { i16, i32, i16 }
> get re-arranged to
> { i16, i16, i32 } or { i32, i16, i16 }

Ok.

> Does LLVM guarantee a consistent code generation in this case for all
> platforms, or is this considered target-specific and a decision left up to
> the back-end of the target platform?

There are two issues: codegen of a specific GEP/type and optimization. 
The code generator currently does very trivial structure layout.  If a 
struct is not "packed", it basically assigns fields sequentially 
consequtive addresses with internal and external padding to make 
alignment.  If the struct is packed, it does the same thing, but inserts 
no padding.

The LLVM optimizer guarantees that it preserves the semantics of the input 
code.  It would be valid for the optimizer to reorder fields, but only 
when it can tell that "noone will notice" (for example, the optimizer 
is not allowed to change the layout of memory-mapped io structs).

> Furthermore if re-arrangement does occur, how does this affect the semantics
> of GetElementPtr when it is used for pointer calculation of a Structure? For
> example if I had:
>
> %BLAH = type { i16, i32, i16 }
> ...
> %firstField = getelementptr %BLAH* %instance, i32 1, i32 0
>
> In this example I want to access the first 16-bit integer field of Structure
> BLAH, so the last argument to GetElementPtr is index 0, but if the fields
> gets re-arranged, how do I know which index to use?

If the optimizer rearranges a struct, it will rewrite all the GEPs to be 
consistent.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/