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

[Jon Chesterfield via llvm-dev]

They are starting to look complicated. The patch linked is interesting,
perhaps v1 vectors are special cased. It shouldn't be too onerous to work
out what one or two in tree back ends do by experimentation.

Thanks again, it's great to have context beyond the source.

On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org>
wrote:

> On 9/15/2017 12:10 PM, Jon Chesterfield wrote:
>
>> OK, I'm clear on scalars. Data races are thankfully OK in this context.
>>
>> Densely packing vectors sounds efficient and is clear in the case where
>> lanes * width is a multiple of 8 bits. I don't think I understand how it
>> works in other cases.
>>
>> If we could take store <4 x i8> truncating to <4 x i7> as an example.
>> This can be converted into four scalar i8 -> i7 stores with corresponding
>> increments to the address, in which case the final layout in memory
>> is 0b01111111011111110111111101111111. Or it can be written as a packed
>> vector which I think would resemble 0b00001111111111111111111111111111.
>>
>> This would mean the memory layout changes depending on how/whether the
>> legaliser breaks large vectors down into smaller types. Is this the case?
>> For example, <4xi32> => <4 x i31> converts to two <2 x i32> => <2 x i31>
>> stores on a target with <2 x i32> legal but would not be split if <4 x i32>
>> were declared legal.
>>
>
> Vectors get complicated; I don't recall all the details of what the code
> generator currently does/is supposed to do.  See also
> https://bugs.llvm.org/show_bug.cgi?id=31265 .
>
>
> -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/20170915/9db3438d/attachment.html>