[PATCH] D42100: Fix codegen of stores of vectors with non byte-sized elements.

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

I've been talking to Jonas about the big-endian question, and I now think that there may actually be open questions about what the layout //should// be.

In general, these are the same questions that need to be answered when laying out a struct type including bitfields.  However, for bitfields you usually have a platform ABI that specifies the precise layout.  But these vector types are LLVM IR types that do not match any high-level language type directly, so really should be defined by LLVM.  I was not able to find any such definition in the IR documentation -- am I missing something here?

Starting with the simple case of <8 x i1>, the question that needs to be answered is, if you convert this to an i8 by either storing to memory and loading the byte, or else doing a bitcast, where in the resulting i8 can you find the elements 0 ... 7 of the original <8 x i1>.  And specifically, should the answer to that question depend on whether the system is big- or little-endian?

Note that comparing this to a bit field that implements a similar type:   struct { char b0 : 1; char b1 : 1; ... char b7 : 1 } ... here, the platform ABI defines where to find the bits b0 .. b7, and this **does** actually differ.  On (most) little-endian machines, b0 is placed in the least-significant bit of the byte in memory, while on (most) big-endian machines, b0 is placed in the most-significant bit.  [ GCC in fact also supports a few rare platforms where this doesn't hold.  I think those are not supported by LLVM today.  ]

Should LLVM define the layout of <8 x i1> the same way?  Or should it impose its own layout, which may be defined independently of byte order?  (Again my question, maybe this **has** been defined and I just don't know where to find this information?)

Once we've decided the simple case, we can probably extend the definition to more complex cases like <7 x i1> or <2 x i3> in a straightforward manner ...


https://reviews.llvm.org/D42100