[LLVMdev] Questions on non-byte-aligned fields

[Reid Kleckner]

In essence, LLVM doesn't lower bitfield operations.  It's the
responsibility of the frontend to lower bitfields to some appropriate
integral type, load that, and mask the relevant bits in and out.

An advantage of this design is that there's only one way to represent
bitfield operations, and the optimizers only have to match one form.  If we
had two ways of representing this, users would file bugs that manual
masking was faster or slower than bitfields.

Another advantage is that it gives the frontend control over width of the
load and store, which is important for implementing memory models with
threads.


On Sun, Apr 13, 2014 at 8:58 AM, Rodney M. Bates <rodney_bates at lcwb.coop>wrote:

> It looks like, for a non-packed struct, that every member starts on a
> byte boundary, even if its size is not a byte multiple, e.g,, i1 or i20.
> And since getelementptr starts with and computes a pointer, it, combined
> with load/store could only be used with this limitation.
>
> So, in the case of a packed struct, can I get fields to start and end
> at non-byte boundaries?  I would still not be able to use getelementptr/
> load/store to access them, but presumably I could use extractvalue and
> insertvalue?
> Can I do this on either memory values or register values?
>
> Even with a field that is a multiple of full bytes, if I were to fetch a
> word from
> memory to a register variable, use extractvalue on that, or use
> insertvalue and then
> store the word, would I lose optimization possibilities that I would have
> if I used
> load or store?
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140413/4eff463e/attachment.html>