<div dir="ltr"><div style="font-size:13px">Bit packing vectors doesn't appear to interact well with splitting or concatenating vectors since it redistributes where the padding goes.</div><div dir="auto" style="font-size:13px"><br></div><div dir="auto" style="font-size:13px">The behaviour I find strange is writing zeros to round up to a byte boundary when storing instead of preserving whatever was already there. Writing a vector of size N bits shouldn't clobber more than N bits of memory.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 9:54 PM, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-">On 9/25/2017 12:13 PM, Björn Pettersson A wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector?<br>
<br>
I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors?<br>
</blockquote></span>
For lack of any formal documentation, the most canonical source of information about the size of a type is DataLayout.  And currently DataLayout::getTypeSizeInBits(<wbr>) assumes vectors are bit-packed.<span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Maybe bit packing should be optional (target specific)?<br>
</blockquote>
<br></span>
That's... maybe possible?  It would break the current rule that whether a bitcast is legal is independent of the target, and I don't see a compelling reason.  (If you're trying to comply with some external ABI, you can always explicitly extend a value before you store it.)<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
-Eli<br>
<br>
-- <br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
</div></div></blockquote></div><br></div></div>