<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 22, 2015 at 1:56 PM, Rodney M. Bates <span dir="ltr"><<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, if I build the llvm struct type with packed attribute, will it just put every field in the<br>
next available bit?  I see the two ways of accessing fields (GEP) and insertvalue/extractvalue<br>
both identify the field with a field sequence number, so I would have to be sure I could control<br>
the way llvm laid the struct out.</blockquote><div><br></div><div>Yes, when you set the packed attribute, each field is laid out on the next available byte. I believe non-byte sized integers are rounded up in size the next byte. To handle padding gaps, the frontend needs to manually insert padding fields, and maintain a mapping from frontend field to LLVM field number. Padding is typically an [i8 x N] array where N is the appropriate size to bring you to the byte boundary of the next field. The advantage is that you can be 100% sure that LLVM and your frontend agree on the layout of the struct, while unpacked structs will have different layouts on different targets.</div><div><br></div><div>The fact that your frontend seems to want to think about things in terms of bits suggests that your next question will be about bitfields. For bitfields, Clang will emit a large integer for all the bits and emit a wide load with extra masking code to extract the relevant bits. All the downstream optimizations are designed to handle this as input, so we should generate good code.</div></div></div></div>