[LLVMdev] Another struct-return question

[Reid Kleckner]

On Thu, Jan 22, 2015 at 1:56 PM, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:
>
> So, if I build the llvm struct type with packed attribute, will it just
> put every field in the
> next available bit?  I see the two ways of accessing fields (GEP) and
> insertvalue/extractvalue
> both identify the field with a field sequence number, so I would have to
> be sure I could control
> the way llvm laid the struct out.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150122/2c9f0b40/attachment.html>