[llvm-dev] What should a truncating store do?
Friedman, Eli via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 15 13:41:33 PDT 2017
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
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the llvm-dev