[LLVMdev] Another struct-return question

[Rodney M. Bates]

On 01/22/2015 04:10 PM, Reid Kleckner wrote:
> On Thu, Jan 22, 2015 at 1:56 PM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto: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.
>

Ah, bytes, not bits.  But I can use that for all fields that start and end on byte boundaries.

FWIW, the reason I care so much is that my front end IR operators that access fields
use bit offsets within the struct and bit sizes, rather than anything that would
identify a field.  But I can de-lower (spell check hates me for that) this to field
numbers if there is agreement on the layout.

> 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.

Yes, that would have been my next question.  I like the answer, as I was worried
about losing optimizations if I generated shift-and-mask code,  which I will use
for non-whole-byte fields.

So the next question is, what about fields that that occupy only whole bytes, but
are not 2^n bytes or aren't aligned to their size.  Should I treat these as
bitfields and produce shift-and-mask operations to access them?

Thanks for the advice.


Rodney Bates
rodney.m.bates at acm.org