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

[Friedman, Eli via llvm-dev]

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