[llvm-dev] What should a truncating store do?
Jon Chesterfield via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 25 14:27:31 PDT 2017
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
On Mon, Sep 25, 2017 at 9:54 PM, Friedman, Eli <efriedma at codeaurora.org>
> 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.)
> 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...
More information about the llvm-dev