Jon Chesterfield via llvm-dev
2017-Sep-25 21:27 UTC
[llvm-dev] What should a truncating store do?
Bit packing vectors doesn't appear to interact well with splitting or concatenating vectors since it redistributes where the padding goes. 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. On Mon, Sep 25, 2017 at 9:54 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:> On 9/25/2017 12:13 PM, Björn Pettersson A wrote: > >> 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? >> >> 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? >> > For lack of any formal documentation, the most canonical source of > information about the size of a type is DataLayout. And currently > DataLayout::getTypeSizeInBits() assumes vectors are bit-packed. > >> Maybe bit packing should be optional (target specific)? >> > > 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.) > > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux > Foundation Collaborative Project > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/d9b65c33/attachment.html>