[llvm-dev] What should a truncating store do?

[Jon Chesterfield via llvm-dev]

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>